LWN: Comments on "Scheduling domains"

Different "length" to memory on the same doamin?

perlid — Thu, 29 Apr 2004 20:44:36 +0000

Just a question:
If you have for example an 8-way Opteron system, then each processor has it's own memory. If a processor wants some data which is in an other processors memory, it has to go through the other processors. But the Opterons are connected in some sort of a ring, so sometimes the data may be just one neighbour away, and sometimes it must go through 2 ( or maybe even more?) processors to get it's data.
For me it looks like all these eight processors are on the same scheduling domain, even though some are "more close" to each other than others?
How does the scheduling domains system handel this?

Scheduling domains

james_northrup — Thu, 29 Apr 2004 19:08:27 +0000

wow very very nice

This effort needs to dovetail with openmosix to seriously improve both fronts of specialized understanding.

Openmosix has a very capable process virtualization model which is elegant and effective, and coincides perfectly with (and benefits greatly from..) domain managed concepts of specific relative wieghted performance windows.

as openmosix ties distributed code execution to the core cpu scheduler, this 3-tier domain hierarchy becomes something truly inspiring with a 4th virtual execution backdrop.

So is this stable?

russell — Thu, 29 Apr 2004 11:03:53 +0000

Don't look at the numbers. Try it out, if it crashes, it's not stable, if it doesn't, then it's stable for you.

So is this stable?

dash2 — Thu, 29 Apr 2004 10:24:59 +0000

As a non-expert, it sounds to me like this is quite a radical new feature. I thought the idea with 2.6 was to avoid the problems of 2.4 where big changes were made throughout the stable series. But we are at 2.6.6 now, and these kind of changes are still being accepted. So what exactly does the designation "stable" for even-numbered kernels mean?

What about threads?

giraffedata — Fri, 23 Apr 2004 21:54:50 +0000

We're actually in a thread/process terminology crisis in Linux. Various people have various ideas about what we should mean by "thread," "process," "task," and "thread group."

It's bad right now because the thread/process model in Linux only recently changed, making what was once a pretty well agreed upon terminology less useful.

So the article is about Linux processes in the old terminology, the terminology you will still see in most of the comments in the Linux code. In that terminology, a "process" is in fact the most basic unit of scheduling known to the Linux kernel, and is what implements a thread in the POSIX thread model. It is alternatively called a "thread" and a "task."

Wait just a minute!

alspnost — Fri, 23 Apr 2004 12:46:01 +0000

Right on - I have learned more about this sort of stuff from LWN than from any other source. I find kernel internals rather fascinating, but trying to learn by reading the raw LKML discussions is completely beyond me, and I have never got very far that way; Jon's kernel articles are superb, and I know of no other place where I can get this type of analysis. It's not watered down or simplified, yet it's expressed in a way that people like us actually have a chance of understanding. A rare talent indeed!

Now, where can I get a nice 8-way NUMA Opteron laptop so that I can play with all this scheduling stuff for real? ;-)

Wait just a minute!

pimlott — Fri, 23 Apr 2004 12:11:16 +0000

You think you're suffering? Think of the poor kernel hackers who are losing their mystique!

What about threads?

hmh — Fri, 23 Apr 2004 00:32:50 +0000

A thread and a process are usually about the same thing in Linux.

What about threads?

stuart2048 — Thu, 22 Apr 2004 20:36:03 +0000

This balancing technique, as it is described here, seems to talk about scheduling processes. But in my notion of the OS world, processes don't actually run -- threads do. So isn't this more about thread scheduling than process scheduling? Granted, I have never poked around any of the scheduler or process management code in Linux, so I could be way off...

I would be interested to learn how this scheduler deals with processes with multiple busy threads on, say, NUMA or SMP hardware.

Thanks for the great article, and keep those cheesy diagrams coming!

--Stuart

Wait just a minute!

heinlein — Thu, 22 Apr 2004 15:51:09 +0000

Jon,

I've got to complain. I'm not much of a hardware guy, nor am I anything close to a kernel hacker. I can blissfully allow my eyes to glaze over whenever I encounter articles that purport to explain the interactions between the kernel and the hardware.

You, however, write much too clearly. I'm pretty sure I actually understood your explanation of scheduling domains. That means that I had to pay attention -- no daydreaming while nominally doing my "professional development" reading. Shame on you.