Neil Conway writes:
> Robert M. Hyatt wrote:
> >
> > Now that 2.2 has hit the ground, I have one topic to suggest for 2.3
> > development. Probably more appropriate in the normal kernel mailing
> > list, but it is a performance issue, and since my machines are SMP-based,
> > maybe it is appropriate here as well.
> >
> > The topic is memory-to-cache mapping.. and the current more-or-less
> > random page allocation approach is fine for most programs, but for those
> > that are _very_ cpu intensive, it leaves a lot to be desired. Since all
> > of the cache systems we are going to see for the forseeable future are
> > going to have some sort of 'direct mapping' at their core (ie 4-way
> > set associative still direct maps to the set) there is going to be a
> > good way to lay out a program in memory (several good ways in fact)
> > but there are far more bad ways. And statistics says we get the bad ways
> > far more often than we get the good ways. :)
> >
> > The issue for me is program optimization. I make a change that obviously
> > results in better instruction scheduling and the program runs slower
> > because now I get less cache performance due to the way the program was
> > loaded _this_ time.
>
> I'm very interested in making codes faster (number-crunching is what we
> do here).
>
> But: I get much more than 2% variations on codes, (try 20%+). It
> depends on the nature of the code, and my feeling is that it's due to
> alignment problems.
>
> I find that running a code under X instead of in a VT can make a huge
> difference for good or for bad (like tens of percent). This is
> surprising to me.
>
> I'm no expert, but I've seen various comments over the last year or two
> which support this view (alignment issues). For some reason, Linux (or
> is it the compiler's fault?) doesn't always ensure decent alignment of
> the critical bits, and this may be worsened when variables are on the
> stack. (When you're using someone else's code which puts lots of things
> on the stack you don't have a lot of options.)
>
> (Perhaps in fact this issue is the same as Robert's cache mapping issue
> but the magnitude of the effect I see is much large than he
> describes...)
>
> Is anyone else up to speed on alignment issues?
Probably cache line aliasing. I've been tracking down these sorts of
variances in my codes and have measured L2 cache misses. I wrote a
primitive coloured page allocator and it fixes the problem. If you
want to measure cache misses and such, see my msr patch at:
http://www.atnf.csiro.au/~rgooch/linux/
Regards,
Richard....
-
Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/mentre/smp-faq/
To Unsubscribe: send "unsubscribe linux-smp" to [EMAIL PROTECTED]
