Re: large page patch (fwd) (fwd)

[ebiederm@xmission.com (Eric W. Biederman)]

Andrew Morton <akpm@zip.com.au> writes:
> 
> The other worry is the ZONE_NORMAL space consumption of pte_chains.
> We've halved that, but it will still make high sharing levels
> unfeasible on the big ia32 machines.  We are dependant upon large
> pages to solve that problem.  (Resurrection of pte_highmem is in
> progress, but it doesn't work yet).

There is a second method to address this.  Pages can be swapped out
of the page tables and still remain in the page cache, the virtual
scan does this all of the time.  This should allow for arbitrary
amounts of sharing.  There is some overhead, in faulting the pages
back in but it is much better than cases that do not work.  A simple
implementation would have a maximum pte_chain length.

For any page that is not backed by anonymous memory we do not need to
keep the pte entries after the page has been swapped of the page
table.  Which should show a reduction in page table size.  In a highly
shared setting with anonymous pages it is likely worth it to promote
those pages to being posix shared memory.

All of the above should allow us to keep a limit on the amount of
resources that go towards sharing, reducing the need for something
like pte_highmem, and keeping memory pressure down in general.

For the cases you describe I have trouble seeing pte_highmem as
anything other than a performance optimization.  Only placing shmem
direct and indirect entries in high memory or in swap can I see as
limit to feasibility.

Eric