Re: NUMA API for Linux

[Andi Kleen]

On Wed, 7 Apr 2004 15:52:25 -0700
Andrew Morton <akpm@xxxxxxxx> wrote:

> Andi Kleen <ak@xxxxxxx> wrote:
> >
> > We can discuss changes when someone shows numbers that additional 
> > optimizations are needed. I haven't seen such numbers and I'm not convinced
> > sharing is even a good idea from a design standpoint.  For the first version 
> > I just aimed to get something working with straight forward code.
> > 
> > To put it all in perspective: a policy is 12 bytes on a 32bit machine
> > (assuming MAX_NUMNODES <= 32) and 16 bytes on a 64bit machine
> > (with MAX_NUMNODES <= 64)
> 
> sizeof(vm_area_struct) is a very sensitive thing on ia32.  If you expect
> that anyone is likely to actually use the numa API on 32-bit, sharing
> will be important.

I don't really believe that. If it was that way someone would have already
done all the obvious space optimizations left on the table...
(like using rb_next or merging the rb color into flags)

NUMA API adds a new pointer, but all sharing in the world couldn't fix that.

When you set a policy != default you will also pay the 12 or 16 bytes overhead
for the object for each "policy region"

> It should be useful for SMT, yes?

Nope. Only for real NUMA.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/