Re: [PATCH 00 of 34] Transparent Hugepage support #14

[Andrea Arcangeli <aarcange@redhat.com>]

On Mon, Mar 22, 2010 at 11:46:01AM -0500, Christoph Lameter wrote:
> On Mon, 22 Mar 2010, Johannes Weiner wrote:
> 
> > > entries while walking the page tables! Go incrementally use what
> > > is there.
> >
> > That only works if you merely read the tables.  If the VMA gets broken
> > up in the middle of a huge page, you definitely have to map ptes again.
> 
> Yes then follow the established system for remapping stuff.

I followed exactly what __pte_alloc does already. When pmds can't go
away after they're established, the only place that uses that locking
is __pte_alloc. Now obviously more stuff will have to use that _same_
locking, because it's not true anymore that a pmd can't go away after
it's established _if_ it's huge.

I also made sure a pmd can't become huge without mmap_sem and anon_vma
rmap lock, so that we can lockless check if pmd is huge, and if it's
not, we just take the legacy 4k paths. That is how it guarantees there
is no measurable slowdown unless you actively use 2M pages and in turn
you get a huge boost (like 50% faster) which outweights any overhead
introduced by having to take the page_table_lock in the pmd_huge new
paths.

It's just pmd_huge -> page_table_lock, not pmd_huge -> call pmd_offset
lockless and take the PT lock.

page_table_lock for pmd_huge acts the _exact_ same way of the PT lock
for the not pmd_huge path.

> It results in a volatility in the page table entries that requires new
> synchronization procedures. It also increases the difficulty in
> establishing a reliable state of the pages / page tables for
> operations since there is potentially on-the-fly atomic conversion
> wizardry going on.

Again: split_huge_page has nothing to do with the pte or pmd locking.

Especially obvious in the case your proposed alternate design will
still use one form of split_huge_page but one that can fail if the
page is under gup (which would practically make it unusable anywhere
but swap and even in swap it would lead to potential livelocks in
unsolvable oom as it's not just slow-unfrequent-IO calling gup).

> You do not need to do this all at once. Again the huge page subsystem has
> been around for years and we have established mechanisms to move/remap.
> There nothing hindering us from implementing huge page -> regular page
> conversion using the known methods or also implementing explicit huge page
> support in more portions of the kernel.

Indeed hugetlbfs also adds page_table_lock around every pmd
manipulation. But personally I prefer you focus on __pte_alloc as
transparent hugepage has to mirror exactly the pte locking to be
clean, regardless of hugetlbfs (in this case hugetlbfs happen to use
the same locking of __pte_alloc and transparent hugepage huge_memory.c).

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