Re: processor affinity

Nick Piggin
2004-10-01T03:10:07Z

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? :)