On Wed, 1 Mar 2006, Andi Kleen wrote:
> I think it's the best default for smaller systems too. I've had people
> complaining about node inbalances that were caused by one or two
> being filled up with d/icache. And the small latencies of accessing
> them don't matter very much.
But these are special situations. Placing memory on a distance node
is not beneficial in the standard case of a single threaded process
churning along opening and closing files etc.
Interleave is only beneficial for special applications that use a common
pool of data and that implement no other means of locality control. At
that point we sacrifice the performance benefit that comes with node locality
in order not to overload a single node.
Kernels before 2.6.16 suffer from special overload situations that are due
to not having the ability to reclaim the pagecache and the slab cache.
This is going to change in SLES10.
> > If you think it would be better to change this default, now that the
> > mechanism is in place to do support spreading these slabs, then I could
> > certainly go along with that.
>
> Yes that would make me happy.
It seems that we are trying to sacrifice the performance of many in
order to accomodate a few special situations. Cpusets are ideal for those
situations since they allow the localization of the interleaving to a
slice of the machine. Processes on the rest of the box can still get node
local memory and run at optimal performance.
> I would be in favour of it
Please run performance tests with single threaded processes if you
do not believe me before doing any of this.
-
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]
