Thread (25 messages) 25 messages, 9 authors, 2017-03-06

Re: [PATCHv3 33/33] mm, x86: introduce PR_SET_MAX_VADDR and PR_GET_MAX_VADDR

From: hpa@zytor.com
Date: 2017-02-17 21:51:00
Also in: linux-arch, linux-mm, lkml

Possibly related (same subject, not in this thread)

On February 17, 2017 1:10:27 PM PST, Linus Torvalds [off-list ref] wrote:
On Fri, Feb 17, 2017 at 1:04 PM, Dave Hansen [off-list ref]
wrote:
quoted
Is this likely to break anything in practice?  Nah.  But it would
nice
quoted
to avoid it.
So I go the other way: what *I* would like to avoid is odd code that
is hard to follow. I'd much rather make the code be simple and the
rules be straightforward, and not introduce that complicated
"different address limits" thing at all.

Then, _if_ we ever find a case where it makes a difference, we could
go the more complex route. But not first implementation, and not
without a real example of why we shouldn't just keep things simple.

             Linus
However, we already have different address limits for different threads and/or syscall interfaces - 3 GiB (32-bit with legacy flag), 4 GiB (32-bit or x32), or 128 TiB... and for a while we had a 512 GiB option, too.  In that sense an address cap makes sense and generalizes what we already have.

It would be pretty hideous for the user, long term, to be artificially restricted to a legacy address cap unless they manage the address space themselves.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help