More Cores Require OS Redesign?

March 27, 2010

Last week, there was a report in Network World on a presentation given by Dave Probert, who works on Windows kernel architecture at Microsoft, on the implications of multiple-core processors for operating system design.  (The article originated with the IDG news services, and was picked up by several industry publications.)  According to the report, Mr. Probert argued that the introduction of processor chips with more and more CPU “cores” means that a new approach to fundamental operating system design is required.

The presentation was given at the Universal Parallel Computing Research Center (of which Microsoft and Intel are sponsors) at the University of Illinois at Urbana-Champaign.   Since the news report was a little light on details, I have tried to get a copy of the presentation, but apparently it is off-limits except to members of the Center.  So I am going to try to discuss the presentation as outlined in the news report; I am aware that possibly it does not accurately or completely represent what Mr. Probert actually said.

The foundation of his argument appears to be that the user is not seeing enough benefit, in terms of greater system responsiveness, from the addition of more processor cores:

Today’s computers don’t get enough performance out of their multicore chips, Probert said. “Why should you ever, with all this parallel hardware, ever be waiting for your computer?” he asked.

Mr. Probert feels that greater responsiveness is what people want.  He says that current methods of scheduling tasks within the operating system are not doing a good job of achieving this, because the system has inadequate knowledge to assign priorities.

The problem in being responsive, he noted, is “how does the OS know [which task] is the important thing?” You don’t want to wait for Microsoft Word to get started because the antivirus program chose that moment to start scanning all your files.

If what he is saying is that application developers are not always careful to provide the information the system needs to set appropriate priorities, then he is right.  If he is saying that the priority mechanisms are incapable of doing a good job, then I have to disagree.  I have mentioned in earlier posts that I often run BOINC applications on my Linux machines.  These run with a very low priority, so that they only get CPU time when no other runnable process wants it; apart from the CPU utilization staying at about 100%, they have no noticeable impact on performance or interactive response.  Of course, if we are talking about an anti-virus program that wants to scan the entire disk, that will take a finite amount of time, and no amount of scheduling cleverness can make it go faster.

One of the remedies that Mr. Probert suggests is to assign specific cores to specific processes, and then let those processes do their own resource management.

The OS could assign an application a CPU and some memory, and the program itself, using metadata generated by the compiler, would best know how to use these resources.

First, at least some current operating systems, like Linux, have a “processor affinity” function, which allows a process to be tied to specific CPU(s) (or cores).  This would seem to accomplish much of what Mr. Probert is talking about.  More fundamentally, though, one of the reasons that people worry about parallel programming, and the key reason the multi-tasking function is provided by the operating system, is that application programmers have a hard time dealing with parallelism well.

As I noted in an earlier post, the degree to which parallel processing is possible is largely an attribute of the problem being solved.  There is also the opportunity for “accidental” parallelism that arises from the mix of processes running on the system at a given time.  It seems clear that only the OS can take advantage of that (of course, the applications designer should “play nice” with the system scheduler).

It may be that there is something in this proposal that I’m missing, or perhaps the reporting was incomplete.  But I don’t really see how the kind of approach that Mr. Probert is suggesting helps in any meaningful way.

%d bloggers like this: