Re: [PATCH/RFC 0/4] VM: Manual and Automatic page cache reclaim

Martin Hicks
2005-05-03T13:21:02Z

On Tue, May 03, 2005 at 01:08:46AM -0700, Andrew Morton wrote:
> Ray Bryant <raybry@engr.sgi.com> wrote:
> >
> > ...
> > One of the common responses to changes in the VM system for optimizations
> > of this type is that we instead should devote our efforts to improving
> > the VM system algorithms and that we are taking an "easy way out" by
> > putting a hack into the VM system.
>
> There's that plus the question which forever lurks around funky SGI patches:
>
> How many machines in the world want this feature?
>
> Because if the answer is "twelve" then gee it becomes hard to justify
> merging things into the mainline kernel. Particularly when they add
> complexity to page reclaim.

And vendors seem hesitant because it isn't upstream.... chicken? egg?

>
> > Fundamentally, the VM system cannot
> > predict the future behavior of the application in order to correctly
> > make this tradeoff.
>
> Yup. But we could add a knob to each zone which says, during page
> allocation "be more reluctant to advance onto the next node - do some
> direct reclaim instead"
>
> And the good thing about that is that it is an easier merge because it's a
> simpler patch and because it's useful to more machines. People can tune it
> and get better (or worse) performance from existing apps on NUMA.

The problem is that it really can't be a machine-wide policy. This is
something that, at the very least, has to be limited to a cpuset. I
chose to use the mempolicy infrastructure because this seemed like the
best method for sending hints to the allocator, based on the first discussion.

> Yes, if it's a "simple" patch then it _might_ do a bit of swapout or
> something. But the VM does prefer to reclaim clean pagecache first (as
> well as slab, which is a bonus for this approach).
>
> Worth trying, at least?

Well, another limitation of this is that we then only get inactive pages
reclaimed. When the reclaim policy is in place the allocator is going
to ignore LRU and try really hard to get local memory.

mh

--
Martin Hicks || Silicon Graphics Inc. || mort@sgi.com