[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20091119035640.GA18236@elte.hu>
Date: Thu, 19 Nov 2009 04:56:40 +0100
From: Ingo Molnar <mingo@...e.hu>
To: Nick Piggin <npiggin@...e.de>
Cc: Jan Beulich <JBeulich@...ell.com>, tglx@...utronix.de,
linux-kernel@...r.kernel.org, hpa@...or.com,
Ravikiran Thirumalai <kiran@...lex86.org>,
Shai Fultheim <shai@...lemp.com>
Subject: Re: [PATCH] x86: eliminate redundant/contradicting cache line size
config options
* Nick Piggin <npiggin@...e.de> wrote:
> The only other use for L1 cache size macro is to pack objects to
> cachelines better (so they always use the fewest number of lines). But
> this case is more rare nowadays people don't really count cachelines
> anymore, but I think even then it makes sense for it to be the largest
> line size in the system because we don't know how big L1s are, and if
> you want opimal L1 packing, you likely also want optimal Ln packing.
We could do that - but then this default of X86_INTERNODE_CACHE_SHIFT:
+ default "7" if NUMA
will bite us and turns the 64 bytes L1_CACHE_BYTES into an effective 128
bytes value.
So ... are you arguing for an increase of the default x86 linesize to
128 bytes?
If yes then i'm not 100% against it, but we need more data and a careful
analysis of the bloat effect: a vmlinux comparizon plus an estimation of
any dynamic bloat effects on this in a representative bootup with an
enterprise distro config. (SLAB uses the dynamic cacheline size value so
it's not affected - but there are some other runtime dependencies on
these kconfig values in the kernel.)
Furthermore, if we do it (double the default line size on x86), then we
in essence will standardize almost everything on
X86_INTERNODE_CACHE_SHIFT and CACHE_BYTES loses much of its meaning. If
we do then we need a vSMP measurement of the effects of this (and an Ack
from the vSMP folks) - it might work - or it might not.
If that all works out fine (which is a big if) then we can also
eliminate INTERNODE_CACHE_SHIFT and just have a single
CACHE_SHIFT/CACHE_BYTES arch tunable.
In any case i will apply Jan's current patch as it certainly is a step
forward that corrects a few inconsistencies and streamlines the status
quo. We can then do another patch to change the status quo.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists