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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

This is not comparable.  The existing remapping code does not have to deal
with structural changes in the page tables.

> > And as already said, allowing it to happen always-succeeding and
> > atomically allows to switch users step by step.
> 
> 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.

I really fail to see how.  Right now, when you want a stable entry, you
take the pte lock.  This is exactly the same for huge page entries.

Migration happens on the fly as well, you can just hide it better for
cases like mremap(), which is unaffected by the actual entries it copies.

It becomes only visible at sites affected by the entries themselves,
which are not that many, the fault handler e.g.  It is much easier to
keep that stuff centralized.

But pmd splitting affects everyone sensitive to the page table structure
itself and that ends up being everyone, well, walking page tables.

> > That sure sounds more incremental to me than being required to do
> > non-trivial adjustments to all the places at once!
> 
> 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.

I see the real complexity in actually dealing with dynamically changing
page table structure and none of the existing code does that.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxxx  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]