Re: processor affinity

[Nick Piggin <nickpiggin@yahoo.com.au>]

jmerkey@galt.devicelogics.com wrote:
> On Thu, Sep 30, 2004 at 12:39:12PM +1000, Nick Piggin wrote:

>>Of course, I don't really have any idea how to interpret patents...

    ^^^
keeping that in mind

> 
> The implementation in NetWare and the Implementation in Linux are 
> similiar but not identical, but they are close enough.  CPU bitmasks were 
> used.  The best apporach would be for someone to locate prior art in the 
> field and challenge the patent in the event any claims were ever brought
> or avoid the same methods.

It seems that the actual patent describes the implementation of the
scheduler that achieves this. And in it, the method used is a locked
global queue and unlocked local queues. But anyway.

> I was able to achieve greater than 
> 100% scaling per processor due to Intel's quirky cache behavior.

And probably most cache behaviours. If you have a set of tasks with
a working set larger than the cache of 1 processor but that can be
divided to fit into the cache of 2, then you're laughing.

More than 1 CPU can dramatically lower task switch (and mm switch)
rates in ideal situations, too.

> If 
> you can get a small subset of code in the cache controllers for 
> processes through hueristics (i.e. guessing) additive processor 
> scaling can be increased dramatically due to taking advantage
> of the L1 and L2 proceesor caches.  Linux is somewhat crude
> from an SMP perspective even today, although it has an impressive
> array of hardware support for SMP systems and architectures, but 
> based on the small number of processes than run on average (< 100)
> this technique would work on Linux.
> 

Well it has pretty strong  CPU affinity, and roughly distributes
load evenly over CPUs. What more do you want? :)