Re: [PATCH 01 of 16] remove nr_scan_inactive/active

Andrew Morton
2007-06-29T00:19:22Z

On Thu, 28 Jun 2007 20:00:03 -0400
Rik van Riel <riel@redhat.com> wrote:

> Andrew Morton wrote:
>
> >> Scanning fewer pages in the pageout path is probably
> >> the way to go.
> >
> > I don't see why that would help. The bottom-line steady-state case is that
> > we need to reclaim N pages per second, and we need to scan N*M vmas per
> > second to do so. How we chunk that up won't affect the aggregate amount of
> > work which needs to be done.
> >
> > Or maybe you're referring to the ongoing LRU balancing thing. Or to something
> > else.
>
> Yes, I am indeed talking about LRU balancing.
>
> We pretty much *know* that an anonymous page on the
> active list is accessed, so why bother scanning them
> all?

Because there might well be pages in there which haven't been accessed in
days. Confused.

> We could just deactivate the oldest ones and clear
> their referenced bits.
>
> Once they reach the end of the inactive list, we
> check for the referenced bit again. If the page
> was accessed, we move it back to the active list.

ok.

> The only problem with this is that anonymous
> pages could be easily pushed out of memory by
> the page cache, because the page cache has
> totally different locality of reference.

I don't immediately see why we need to change the fundamental aging design
at all. The problems afacit are

a) that huge burst of activity when we hit pages_high and

b) the fact that this huge burst happens on lots of CPUs at the same time.

And balancing the LRUs _prior_ to hitting pages_high can address both
problems?

It will I guess impact the page aging a bit though.

> The page cache also benefits from the use-once
> scheme we have in place today.
>
> Because of these three reasons, I want to split
> the page cache LRU lists from the anonymous
> memory LRU lists.
>
> Does this make sense to you?

Could do, don't know. What new problems will it introduce? :(

> >> No matter how efficient we make the scanning of one
> >> individual page, we simply cannot scan through 1TB
> >> worth of anonymous pages (which are all referenced
> >> because they've been there for a week) in order to
> >> deactivate something.
> >
> > Sure. And we could avoid that sudden transition by balancing the LRU prior
> > to hitting the great pages_high wall.
>
> Yes, we will need to do some preactive balancing.

OK..

And that huge anon-vma walk might need attention. At the least we could do
something to prevent lots of CPUs from piling up in there.