Messages in this thread | | | From | Andi Kleen <> | Subject | Re: [PATCH 01/02] cpuset memory spread slab cache filesys | Date | Wed, 1 Mar 2006 21:59:41 +0100 |
| |
On Wednesday 01 March 2006 21:53, Paul Jackson wrote: > > > 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. > > As a result of your general concern with the performance impact > of cpusets on the page allocation code path, I optimized each > element of it, not just the one case covered by your specific > recommendation.
Thanks for doing that work then.
> > > Using a single cpuset would already drop into the slow path, right? > > No - having a single cpuset is the fastest path. All tasks > are in that root cpuset in that case, and all nodes allowed.
Faster than no cpuset?
> > > I'm not sure I want to get into the business > > of explaining all the distributions how to set up cpusets .. > > Good grief - I already quoted the 3 lines of boottime init script it > would take - this can't require that much explaining, and your new > sysctl can't get by with much less:
It would just be on by default - no user space configuration needed.
> And even from the perspective of maintaining Linux, this should be on > autopilot. Every file systems inode cache is marked, and if we do > nothing, as more file system types are invented for Linux, they will > predictably cut+paste the inode slab cache setup from an existing file > system, and "just get it right."
If something is a good default it shouldn't need user space configuration at all imho. Only the "weird" cases should.
> I just don't see that it serves any purpose, and I suspect that > misunderstandings of the performance impact of cpusets are the > primary source of motivation for such a sysctl.
No that was just one. The other was having good defaults even on lightweight kernels.
-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/
| |