swapout frenzy solution

swapout frenzy solution

[Rik van Riel]

Hi Linus,

I've just come up with a simple 'solution' for the swapout
frenzy experienced by the recent free_memory_available()
test in kswapd.

We simply stop kswapd when nr_free_pages > free_pages_high * 4.
Since page allocation always assigns a page from the smallest
possible unit, the larger free areas are extremely likely to
grow bigger and bigger, especially when nr_free_pages is very
large, say > 3 * free_pages_high.

Since my vmscan.c is somewhat different from yours, and since
I don't know what you have done to it in the last week, I
won't send you a diff.

(trying to merge a faulty diff is _far_ more work than
doing the 30 second edit yourself :-)

I'm trying it now, and I don't see any swapout frenzies
occurring anymore...

Rik.
+-----------------------------+------------------------------+
| For Linux mm-patches, go to | "I'm busy managing memory.." |
| my homepage (via LinuxHQ).  | H.H.vanRiel@fys.ruu.nl       |
| ...submissions welcome...   | http://www.fys.ruu.nl/~riel/ |
+-----------------------------+------------------------------+

Re: swapout frenzy solution

[Rik van Riel]

On Thu, 5 Mar 1998, Rik van Riel wrote:

> I've just come up with a simple 'solution' for the swapout
> frenzy experienced by the recent free_memory_available()
> test in kswapd.

Hate to follow up to my own posts, but here it goes:
Once my system reached a state where it needed to
free a _large_ (MAX_ORDER) area, nr_free_pages kept
lingering around free_pages_high * 4 :-(
This means that this scheme doesn't really work...

Then I've got another possible solution. In try_to_swap_out,
we:
- test what page-order this page is holding up
- change the following:
  if (page->age)
- into:
  if (page->age - order_block(page))

This means that a page blocking an order-5 area will
be heavily penalized for this, so this page will be
freed earlier than other pages (which don't occupy
'critical' regions.

Of course, reserving 1/16th of memory for exclusive
use by the page and buffer cache (which we can already
clean on a page-by-page basis) will be far superior
to this...

I don't have time to code this up before the weekend,
so you've got all the time to decide which solution
you'd like to see implemented...

Rik.
+-----------------------------+------------------------------+
| For Linux mm-patches, go to | "I'm busy managing memory.." |
| my homepage (via LinuxHQ).  | H.H.vanRiel@fys.ruu.nl       |
| ...submissions welcome...   | http://www.fys.ruu.nl/~riel/ |
+-----------------------------+------------------------------+