Re: [PATCH][1/2] return values shrink_dcache_memory etc

[Andrew Morton]

William Lee Irwin III wrote:
> 
> On Sun, Jul 21, 2002 at 10:04:29PM -0700, Andrew Morton wrote:
> > 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:
> > 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.

-