Re: 2.5isms

[Nick Piggin]

Andi Kleen wrote:
> Nick Piggin <nickpiggin@xxxxxxxxxxxx> writes:
>
>
> > Justin Pryzby wrote:
> >
> > > Hi all, I have more 2.5isms for the list.  ./fs/binfmt_elf.c:
> > >  #ifdef CONFIG_X86_HT
> > >                  /*
> > >                   * In some cases (e.g. Hyper-Threading), we want to avoid L1
> > >                   * evictions by the processes running on the same package. One
> > >                   * thing we can do is to shuffle the initial stack for them.
> > >                   *
> > >                   * The conditionals here are unneeded, but kept in to make the
> > >                   * code behaviour the same as pre change unless we have
> > >                   * hyperthreaded processors. This should be cleaned up
> > >                   * before 2.6
> > >                   */
> > >                  if (smp_num_siblings > 1)
> > >                          STACK_ALLOC(p, ((current->pid % 64) << 7));
> > >  #endif
> >
> > Can we just kill it? Or do it unconditionally? Or maybe better yet, wrap
> > it properly in arch code?
>
>
> You can't kill it without ruining performance on older HT CPUs.
> I would just keep it, it fixes the problem perhaps with a small amount of 
> code. A more generalized #ifdef may be a good idea (NEED_STACK_RANDOM)
> may be a good idea, but it is not really a pressing need. Enabling 
> it unconditionally may be an option, although it will make it harder
> to repeat test runs on non hyperthreaded CPUs.

Interesting. Yeah something like Arjan posted looks better then... having
CONFIG_X86_HT in generic code is obviously pretty ugly.

I'm curious about a couple of points though. First, is that it is basically
just adding a cache colouring to the stack, right? In that case why do only
older HT CPUs have bad performance without it? And wouldn't it possibly make
even non HT CPUs possibly slightly more efficient WRT caching the stacks of
multiple processes?

Second, on what workloads does performance suffer, can you remember? I wonder
if natural variations in the stack pointer as the program runs would mitigate
the effect of this on all but micro benchmarks?

But even if that were so so, it seems simple enough that I don't have any
real problem with keeping it of course.

Thanks,
Nick
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/