Messages in this thread | | | Date | Mon, 03 Jan 2005 11:49:31 +1100 | From | Nick Piggin <> | Subject | Re: 2.5isms |
| |
Arjan van de Ven wrote: >>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? > > > it's a win on more than older HT cpus. It's just that those suffer it > the most... (since there you have 2 "cpus" share the cache, meaning you > get double the aliasing) > > > >>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? > > > one of the problem cases I remember is network daemons all waiting in > accept() for connections. All from the same codepath basically. > Randomizing the stackpointer is a gain for that on all cpus that have > finite affinity on their caches. >
I see. Yes, that would be a prime candidate.
> > >>But even if that were so so, it seems simple enough that I don't have any >>real problem with keeping it of course. > > > The reason my patch does it much more is that it makes it a step harder > to write exploits for stack buffer overflows. > >
Oh yeah I realised that. I just meant specifically the code to do arch specific stack colouring.
Thanks Nick - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |