On 11/11/2014 10:27 AM, Thomas Gleixner wrote:
> On Thu, 6 Nov 2014, Dave Hansen wrote:
>> Instead of all of these games with dropping and reacquiring mmap_sem and
>> adding other locks, or deferring the work, why don't we just do a
>> get_user_pages()? Something along the lines of:
>>
>> while (1) {
>> ret = cmpxchg(addr)
>> if (!ret)
>> break;
>> if (ret == -EFAULT)
>> get_user_pages(addr);
>> }
>>
>> Does anybody see a problem with that?
>
> You want to do that under mmap_sem write held, right? Not a problem per
> se, except that you block normal faults for a possibly long time when
> the page(s) need to be swapped in.
Yeah, it might hold mmap_sem for write while doing this in the unmap
path. But, that's only if the bounds directory entry has been swapped
out. There's only 1 pointer of bounds directory entries there for every
1MB of data, so it _should_ be relatively rare. It would mean that
nobody's been accessing a 512MB swath of data controlled by the same
page of the bounds directory.
If it gets to be an issue, we can always add some code to fault it in
before mmap_sem is acquired.
FWIW, I believe we have a fairly long road ahead of us to optimize MPX
in practice. I have a list of things I want to go investigate, but I
have not looked in to it in detail at all.
> But yes, this might solve most of the issues at hand. Did not think
> about GUP at all :(
Whew. Fixing it was getting nasty and complicated. :)
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>