Messages in this thread | | | Date | Thu, 8 Apr 2004 01:35:22 +0200 | From | Andi Kleen <> | Subject | Re: NUMA API for Linux |
| |
On Wed, 7 Apr 2004 15:52:25 -0700 Andrew Morton <akpm@osdl.org> wrote:
> Andi Kleen <ak@suse.de> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |