On 02/16/2016 01:54 AM, Kirill A. Shutemov wrote:

On Fri, Feb 12, 2016 at 08:54:58AM -0800, Dave Hansen wrote:

quoted

On 02/11/2016 06:21 AM, Kirill A. Shutemov wrote

quoted

We also shouldn't try to mlock() pte-mapped huge pages: pte-mapeed THP
pages are never mlocked.

That's kinda subtle.  Can you explain more?

If we did the following:

	ptr = mmap(NULL, 512*PAGE_SIZE, ...);
	mlock(ptr, 512*PAGE_SIZE);
	fork();
	munmap(ptr + 100 * PAGE_SIZE, PAGE_SIZE);

I'd expect to get two processes, each mapping the same compound THP, one
with a PMD and the other with 511 ptes and one hole.  Is there something
different that goes on?

I'm not sure what exactly you want to ask with this code, but it will have
the following result:

 - After fork() process will split the pmd in munlock(). For file thp
   split pmd, means clear it out. Mapping split_huge_pmd() would munlock
   the page as we do for anon thp;

 - In child process the page is never mapped as mlock() is not inherited
   and we don't copy page tables for shared VMA as they can re-faulted
   later;

Huh, I didn't realize we don't inherit mlock() across fork(). Learn
something every day!

The basic semantic for mlock()ed file THP would be the same as for anon
THP: we only keep the page mlocked as long as it's mapped only with PMDs.
This way it's relatively simple to make sure that we don't leak mlocked
pages.

Ahh, I forgot about that bit.  Could you add some of that description to
the changelog so I don't forget again?

--
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>