Messages in this thread | | | From | Andi Kleen <> | Subject | Re: [PATCH 01/02] cpuset memory spread slab cache filesys | Date | Wed, 1 Mar 2006 20:21:58 +0100 |
| |
On Wednesday 01 March 2006 19:58, Paul Jackson wrote: > Andi wrote: > > The main reason i'm reluctant to use this is that the cpuset fast path > > overhead (e.g. in memory allocators etc.) is quite large > > I disagree. > > I spent much time minimizing that overhead over the last few months, as > a direct result of your recommendation to do so.
IIRC my recommendation only optimized the case of nobody using cpuset if I remember correctly.
Using a single cpuset would already drop into the slow path, right?
Hmm, possibly it's better now, but I remember being shocked last time I looked at the code in detail ow much code it executed for a normal page allocation and how many cache lines it touched. This was some time ago admittedly.
Also on a different angle I would like to make the dcache/inode spreading basically default on x86-64 and I'm not sure I want to get into the business of explaining all the distributions how to set up cpusets and set up new file systems. For that a single switch that can be just set by default is much more practical.
> > Especially in the case that all tasks are in the root cpuset (as in the > scenario I just suggested for setting this memory spreading policy for > all tasks), the overhead is practically zero.
Ok.
> The key hook is an > inline test done (usually) once per page allocation on an essentially > read only global 'number_of_cpusets' that determines it is <= 1. > > I disagree with your "quite large" characterization.
Agreed perhaps it was somewhat exaggerated.
-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/
| |