linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Rik van Riel <riel@redhat.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH -mm] vmscan: bail out of page reclaim after swap_cluster_max pages
Date: Fri, 14 Nov 2008 09:36:28 -0500	[thread overview]
Message-ID: <491D8CEC.5050106@redhat.com> (raw)
In-Reply-To: <20081113192729.7d8eb133.akpm@linux-foundation.org>

Andrew Morton wrote:
> On Thu, 13 Nov 2008 17:12:08 -0500 Rik van Riel <riel@redhat.com> wrote:
> 
>> Sometimes the VM spends the first few priority rounds rotating back
>> referenced pages and submitting IO.  Once we get to a lower priority,
>> sometimes the VM ends up freeing way too many pages.
>>
>> The fix is relatively simple: in shrink_zone() we can check how many
>> pages we have already freed and break out of the loop.
>>
>> However, in order to do this we do need to know how many pages we already
>> freed, so move nr_reclaimed into scan_control.
> 
> There was a reason for not doing this, but I forget what it was.  It might require
> some changelog archeology.  iirc it was to do with balancing scanning rates
> between the various things which we scan.

I've seen worse symptoms without this code, though. Pretty
much all 2.6 kernels show bad behaviour occasionally.

Sometimes the VM gets in such a state where multiple processes
cannot find anything readily evictable, and they all end up
at a lower priority level.

This can cause them to evict more than half of everything from
memory, before breaking out of the pageout loop and swapping
things back in.  On my 2GB desktop, I've seen as much as 1200MB
memory free due to such a swapout storm.  It is possible more is
free at the top of the cycle, but X and gnome-terminal and top
and everything else is stuck, so that's not actually visible :)

I am not convinced that a scanning imbalance is more serious.

Of course, one thing we could do is exempt kswapd from this check.
During light reclaim, kswapd does most of the eviction so scanning
should remain balanced.  Having one process fall down to a lower
priority level is also not a big problem.

As long as the direct reclaim processes do not also fall into the
same trap, the situation should be manageable.

Does that sound reasonable to you?

-- 
All rights reversed.

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2008-11-14 14:36 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-13 22:12 Rik van Riel
2008-11-14  0:51 ` KOSAKI Motohiro
2008-11-14  3:27 ` Andrew Morton
2008-11-14 14:36   ` Rik van Riel [this message]
2008-11-14 17:18     ` Andrew Morton
2008-11-16  7:43       ` KOSAKI Motohiro
2008-11-16  7:54         ` Andrew Morton
2008-11-16  7:56           ` KOSAKI Motohiro
2008-11-16  8:02             ` Andrew Morton
2008-11-22 10:22           ` KOSAKI Motohiro
2008-11-22 16:57             ` Rik van Riel
2008-11-24 19:12               ` KOSAKI Motohiro
2008-11-24 19:18                 ` Rik van Riel
2008-11-16  7:38 ` KOSAKI Motohiro
2008-11-17  0:38   ` KAMEZAWA Hiroyuki
2008-11-17  3:43     ` Balbir Singh
2008-11-19 16:54 ` Mel Gorman
2008-11-21 11:59   ` Petr Tesarik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=491D8CEC.5050106@redhat.com \
    --to=riel@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox