> > 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.
Take a look.
> 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.
> 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:
test -d /dev/cpuset || mkdir /dev/cpuset
mount -t cpuset cpuset /dev/cpuset
echo 1 > /dev/cpuset/memory_spread_slab # enable system wide
> and set up new file systems.
That's a Linux source issue that matters a single time in the history
of each file system type supported by Linux. It is not a customer or
even distro issue.
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."
> For that a single switch that can be just set by default is much more
> practical.
Doing it via cpusets is also a single switch that is set by default.
It is just as practical; well more practical - it's already there.
===
Mind you, I don't have any profound objections to such a sysctl.
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.
I prefer to (1) set the record straight on cpusets, and (2) avoid
adding additional kernel mechanisms that are redundant.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[email protected]> 1.925.600.0401
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
