Re: [PATCH 00 of 30] Transparent Hugepage support #3

[Andrea Arcangeli <aarcange@redhat.com>]

On Mon, Jan 25, 2010 at 03:50:31PM -0600, Christoph Lameter wrote:
> There is always VM activity, so we need 512 pointers sigh.

well you said some week ago that actual systems never swap and swap is
useless... if they don't swap there will be just 1 pointer in the
pmd. The mprotect/mremap we want to learn using pmd_trans_huge
natively without split but again, this is incremental work.

> So its not possible to use these "huge" pages in a useful way inside of
> the kernel. They are volatile and temporary.

They are so useless that firefox never splits them, this is my
laptop. khugepaged running so if there's swapout, after swapin they
will be collapsed back into hugepages.

AnonPages:        357148 kB
AnonHugePages:     53248 kB

> In short they cannot be treated as 2M entities unless we add some logic to
> prevent splitting.

They can on the physical side, splitting only involves the virtual
side, this is why O_DIRECT DMA through gup already works on hugepages
without splitting them.

> Frankly this seems to be adding splitting that cannot be used if one
> really wants to use large pages for something.
> 
> I still think we should get transparent huge page support straight up
> first without complicated fallback schemes that makes huge pages difficult
> to use.

Just send me patches to remove all callers of split_huge_page, then
split_huge_page can go away too. But saying that hugepages aren't
useful already is absurd, kvm with "madvise" default of sysfs already
gets the full benefit, nothing more can be achieved by kvm in
performance and functionality than what my patch delivers already
(ok swapping will be a little more efficient if done through 2M I/O
but swap performance isn't so critical). Our objective is to over time
eliminate the need of split_huge_page. khugepaged will remain required
forever, unless the whole kernel ram will become relocatable and
defrag not just an heuristic but a guarantee (it is needed after one
VM exits and release several gigs of hugepages, so the other VM get
the speedup).

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