--Hugh Dickins <[EMAIL PROTECTED]> wrote (on Wednesday, August 31, 2005 14:42:38 +0100):
> On Wed, 31 Aug 2005, Arjan van de Ven wrote: >> On Wed, 2005-08-31 at 12:44 +0100, Hugh Dickins wrote: >> > I was going to say, doesn't randomize_va_space take away the rest of >> > the point? But no, it appears "randomize_va_space", as it currently >> > appears in mainline anyway, is somewhat an exaggeration: it just shifts >> > the stack a little, with no effect on the rest of the va space. >> >> it also randomizes mmaps > > Ah, via PF_RANDOMIZE, yes, thanks: so long as certain conditions are > fulfilled - and my RLIM_INFINITY RLIMIT_STACK has been preventing it. > > And mmaps include shmats: so unless the process specifies non-NULL > shmaddr to attach at, it'll choose a randomized address for that too > (subject to those various conditions). > > Which is indeed a further disincentive against shared page tables. Or shared pagetables a disincentive to randomizing the mmap space ;-) They're incompatible, but you could be left to choose one or the other via config option. 3% on "a certain industry-standard database benchmark" (cough) is huge, and we expect the benefit for PPC64 will be larger as we can share the underlying hardware PTEs without TLB flushing as well. M. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
