William Lee Irwin III wrote:

On Sun, Jul 21, 2002 at 10:04:29PM -0700, Andrew Morton wrote:

quoted

I'd suggest that we avoid putting any additional changes into
the VM until we have solutions available for:
2: Make it work with pte-highmem  (Bill Irwin is signed up for this)
4: Move the pte_chains into highmem too (Bill, I guess)
6: maybe GC the pte_chain backing pages. (Seems unavoidable.  Rik?)
Especially pte_chains in highmem.  Failure to fix this well
is a showstopper for rmap on large ia32 machines, which makes
it a showstopper full stop.

I'll send you an update of my solution for (6), the initial version of
which was posted earlier today, in a separate post.

Thanks, Bill.  Yup, I'm playing with pte_chain_mempool at present.

highpte_chain will do (2) and (4) simultaneously when it's debugged.

On Sun, Jul 21, 2002 at 10:04:29PM -0700, Andrew Morton wrote:

quoted

If we can get something in place which works acceptably on Martin
Bligh's machines, and we can see that the gains of rmap (whatever
they are ;)) are worth the as-yet uncoded pains then let's move on.
But until then, adding new stuff to the VM just makes a `patch -R'
harder to do.

I have the same kinds of machines and have already been testing with
precisely the many tasks workloads he's concerned about for the sake of
correctness, and efficiency is also a concern here. highpte_chain is
already so high up on my priority queue that all other work is halted.

OK.  But we're adding non-trivial amounts of new code simply
to get the reverse mapping working as robustly as the virtual
scan.  And we'll always have rmap's additional storage requirements.

At some point we need to make a decision as to whether it's all
worth it.  Right now we do not even have the information on the
pluses side to do this.  That's worrisome.

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