--Hugh Dickins [off-list ref] wrote (on Wednesday, August 31, 2005 14:42:38 +0100):

On Wed, 31 Aug 2005, Arjan van de Ven wrote:

quoted

On Wed, 2005-08-31 at 12:44 +0100, Hugh Dickins wrote:

quoted

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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>