On Thu, 20 Jun 2013, Ingo Molnar wrote:
> Peter clearly pointed it out that in the perf case it's user-space that
> initiates the pinned memory mapping which is resource-controlled via
> RLIMIT_MEMLOCK - and this was implemented that way before your commit
> broke the code.
There is no way that user space can initiate a page pin right now. Perf is
pinning the page from the kernel. Similarly the IB subsystem pins memory
meeded for device I/O.
> You seem to be hell bent on defining 'memory pinning' only as "the thing
> done via the mlock*() system calls", but that is a nonsensical distinction
> that actively and incorrectly ignores other system calls that can and do
> pin memory legitimately.
Nope. I have said that Memory pinning is done by increasing the refcount
which is different from mlock which sets a page flag.
I have consistently argued that these are two different things. And I am
a
bit surprised that this point has not been understood after all these
repetitions.
Memory pinning these days is done as a side effect of kernel / driver
needs. I.e. the memory registration done through the IB subsystem and
elsewhere.
> int can_do_mlock(void)
> {
> if (capable(CAP_IPC_LOCK))
> return 1;
> if (rlimit(RLIMIT_MEMLOCK) != 0)
> return 1;
> return 0;
> }
> EXPORT_SYMBOL(can_do_mlock);
>
> Q.E.D.
Argh. Just checked the apps. True. They did set the rlimit to 0 at some
point in order to make this work. Then they monitor the number of locked
pages and create alerts so that action can be taking if a system uses too
many mlocked pages.
--
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>