On Mon, 17 Dec 2007 02:33:39 -0800 Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > On Fri, 14 Dec 2007 01:33:45 +0100 Andi Kleen <andi@xxxxxxxxxxxxxx> wrote: > > > Kyle McMartin <kyle@xxxxxxxxxxx> writes: > > > > > I'd bet, in the __read_mostly case at least, that there's no > > > improvement in almost all cases. > > > > I bet you're wrong. Cache line behaviour is critical, much more > > than pipeline behaviour (which unlikely affects). That is because > > if you eat a cache miss it gets really expensive, which e.g. > > a mispredicted jump is relatively cheap in comparison. We're talking > > one or more orders of magnitude. > > So... once we've moved all read-mostly variables into __read_mostly, what > is left behind in bss? > > All the write-often variables. All optimally packed together to nicely > maximise cacheline sharing. This is why it's important to group related variables together, so that they share same cacheline. Random example : vmlist_lock & vmlist Currently in two separate cache lines (not that important since vmlist is so big that one extra cache line access is not measurable) Other possibilities are : 1) to make sure that really critical hot spots are alone (they eventually waste a full cacheline, even if only 4 bytes are in use) 2) Or they are mixed with seldom used data. (One cache line contains one critical object + other mostly_unused data). This kind of mixing is really hard to do without a special linker. - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
