Scenes from the Real Time Linux Workshop [LWN.net]

Scenes from the Real Time Linux Workshop

Posted Oct 6, 2009 2:46 UTC (Tue) by Viddy (subscriber, #33288)
Parent article: Scenes from the Real Time Linux Workshop

I'm doing the a Operating Systems postgraduate course this semester at a NZ University, and
the class at the beginning of the semester had three choices on
what to study, a lecture/assignments/exam or a lecture/big assignments/no exam
using Linux, or a lecture/big assignments option in Minix.
The class overwhelmingly chose to go down the Minix path, ostensibly as it would be simpler
and cover more topics, rather than the few specific areas in the Linux kernel, which some
of the class voiced as being "complicated".
The flip side of this is that the lecturer has more than made up for the "uncomplicated"
nature of Minix with large volumes of readings and difficult assignments.
Universities differ (In my opinion) to prescriptive technical institutions by teaching their
students a framework of how a system works, rather than how a specific instance of a system
works.
In the instance of the paper I did, has this translated to a framework for getting to an
understanding how other kernels work? I think it may have - things like syscalls and process
scheduling now make a lot more sense than they used to.

On the quote about microkernels, I had to revise some assumptions I had about the message
passing methodology being a hideous waste of resources after reading the barrelfish paper at
http://barrelfish.org/barrelfish_sosp09.pdf after seeing the benchmarks at the end of the
paper. Short version seems to be that on large multicore systems, ccNUMA doesn't scale, and
specific message passing between cores and sockets seems to be a good idea, though I'm not
quite clear how exactly the kernel running on each core passes messages around inside the
core.

My observations on university classes that I've attended are that there are some very good
students, who at postgrad level are finally being stretched and will end up doing great
things either in the kernel or elsewhere, there are a few good students who will also do
good works, and there rest will probably go on to work with the languages that they've been
using at Uni.
I'm not terribly sure that this has changed much from when I finished my undergraduate
degree in Chemistry 6 or so years ago (I should know, I was one of the crap ones back
then), and I wonder if comments to the contrary from the audience are another form of "Back
in my day"?

(Log in to post comments)

Scenes from the Real Time Linux Workshop

Posted Oct 6, 2009 13:17 UTC (Tue) by drag (subscriber, #31333) [Link]

I don't know how much it applies to your situation, but I've come across
the realization that education is vastly different from training,
especially when it comes to computer science.

Many, it seems, enter into a university CS degree program with the
intention that it is going to give them qualifications to get a job later
on.. and many employers expect CS degrees as a way to find qualified people
to work on their corporate applications.

All of this is really really bad.

Most people would probably be much better served by having a vocational
training school were they learn to program and deal with real-world
situations using existing technology and concepts. Learn some CS, to be
true, but mostly just concentrate on understanding existing systems and
practical application of programming in the real world situation.

I don't think it is too much about "good" vs "bad" students, its just about
what people actually want through their education.. if people are not
really interested in CS as a discipline, but are interested in programing
as a career then there should be a acceptable and employer-friendly outlet
for people like that.

Were as people that are more interested in research and mathematics and are
passionate about pushing technology and that sort of thing should still
have CS to throw themselves at.

Its like you don't need to have a degree in physics to be a excellent
mechanic or automobile engineer. You need to know some physics, chemistry,
and metalergy; but it is more about finding creative ways to apply known
concepts and practices rather then pushing the boundaries of knowledge.
Just like to be a physicist you don't need to know how to weld or
understand the proper techniques to aid in the creation of crystals in the
form of grain in the metal that will either increase the strength and
flexibility or increase stiffness at the expense of brittleness based on
the application of heat and coolness to the metal prior and after wielding
it.

--------------------------

Its like the Minix vs Linux thing. Real-world software systems are very
complex. Unless you have a way to deal and work within that complexity then
your solutions are worthless to people that care about making software
people can use.

Scenes from the Real Time Linux Workshop

Posted Oct 6, 2009 23:56 UTC (Tue) by PaulWay (✭ supporter ✭, #45600) [Link]

> Short version seems to be that on large multicore systems, ccNUMA doesn't scale, and specific message passing between cores and sockets seems to be a good idea, though I'm not quite clear how exactly the kernel running on each core passes messages around inside the core.

I think the idea is that the message passing code deals with the different interfaces much like we deal with network interfaces - they use different signalling mechanisms and throughput logic for each interface. If one kernel wants to talk to a core on the same chip, it uses a different (optimised) interface to that used for talking to the other chip on the same motherboard, or on the GPU.

I'm glad you showed me the barrelfish paper, because it gave me an insight. If we're using 'network' interfaces to talk to each kernel, then we can use actual network interfaces as well. Why not boot up another machine and have its kernels 'join' your machine's kernels across the network? Sure, you've got much larger latencies, no shared memory and different failure modes; but it's just another interface, these concepts are already well understood. You can also have processors joining and leaving different kernels on an as-needs basis.

It brings the realm of ubiquitous, scalable computing that bit closer.

Have fun,

Paul