From: Andrew Morton <akpm@linux-foundation.org>
To: Mandeep Singh Baines <msb@chromium.org>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Rik van Riel <riel@redhat.com>, Mel Gorman <mel@csn.ul.ie>,
Minchan Kim <minchan.kim@gmail.com>,
Johannes Weiner <hannes@cmpxchg.org>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
wad@chromium.org, olofj@chromium.org, hughd@chromium.org
Subject: Re: [PATCH] RFC: vmscan: add min_filelist_kbytes sysctl for protecting the working set
Date: Thu, 28 Oct 2010 13:10:29 -0700 [thread overview]
Message-ID: <20101028131029.ee0aadc0.akpm@linux-foundation.org> (raw)
In-Reply-To: <20101028191523.GA14972@google.com>
On Thu, 28 Oct 2010 12:15:23 -0700
Mandeep Singh Baines <msb@chromium.org> wrote:
> On ChromiumOS, we do not use swap.
Well that's bad. Why not?
> When memory is low, the only way to
> free memory is to reclaim pages from the file list. This results in a
> lot of thrashing under low memory conditions. We see the system become
> unresponsive for minutes before it eventually OOMs. We also see very
> slow browser tab switching under low memory. Instead of an unresponsive
> system, we'd really like the kernel to OOM as soon as it starts to
> thrash. If it can't keep the working set in memory, then OOM.
> Losing one of many tabs is a better behaviour for the user than an
> unresponsive system.
>
> This patch create a new sysctl, min_filelist_kbytes, which disables reclaim
> of file-backed pages when when there are less than min_filelist_bytes worth
> of such pages in the cache. This tunable is handy for low memory systems
> using solid-state storage where interactive response is more important
> than not OOMing.
>
> With this patch and min_filelist_kbytes set to 50000, I see very little
> block layer activity during low memory. The system stays responsive under
> low memory and browser tab switching is fast. Eventually, a process a gets
> killed by OOM. Without this patch, the system gets wedged for minutes
> before it eventually OOMs. Below is the vmstat output from my test runs.
>
> BEFORE (notice the high bi and wa, also how long it takes to OOM):
That's an interesting result.
Having the machine "wedged for minutes" thrashing away paging
executable text is pretty bad behaviour. I wonder how to fix it.
Perhaps simply declaring oom at an earlier stage.
Your patch is certainly simple enough but a bit sad. It says "the VM
gets this wrong, so lets just disable it all". And thereby reduces the
motivation to fix it for real.
But the patch definitely improves the situation in real-world
situations and there's a case to be made that it should be available at
least as an interim thing until the VM gets fixed for real. Which
means that the /proc tunable might disappear again (or become a no-op)
some time in the future.
--
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>
next prev parent reply other threads:[~2010-10-28 20:11 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-28 19:15 [PATCH] RFC: vmscan: add min_filelist_kbytes sysctl for protecting the working set Mandeep Singh Baines
2010-10-28 20:10 ` Andrew Morton [this message]
2010-10-28 22:03 ` Mandeep Singh Baines
2010-10-28 23:28 ` Minchan Kim
2010-10-28 23:29 ` Minchan Kim
2010-10-29 0:04 ` KAMEZAWA Hiroyuki
2010-10-29 0:28 ` Minchan Kim
2010-10-28 21:30 ` Rik van Riel
2010-10-28 22:13 ` Mandeep Singh Baines
2010-11-01 7:05 ` KOSAKI Motohiro
2010-11-01 18:24 ` Mandeep Singh Baines
2010-11-01 18:50 ` Rik van Riel
2010-11-01 19:43 ` Mandeep Singh Baines
2010-11-02 3:11 ` Rik van Riel
2010-11-03 0:48 ` Minchan Kim
2010-11-03 2:00 ` Rik van Riel
2010-11-03 3:03 ` Minchan Kim
2010-11-03 11:41 ` Rik van Riel
2010-11-03 15:42 ` Minchan Kim
2010-11-03 22:40 ` Mandeep Singh Baines
2010-11-03 23:49 ` Minchan Kim
2010-11-04 15:30 ` Rik van Riel
2010-11-08 21:55 ` Mandeep Singh Baines
2010-11-09 2:49 ` KOSAKI Motohiro
2010-11-01 23:46 ` Minchan Kim
2010-11-04 1:52 ` Mandeep Singh Baines
2010-11-05 2:36 ` Minchan Kim
2010-11-09 2:53 ` KOSAKI Motohiro
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=20101028131029.ee0aadc0.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=hughd@chromium.org \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mel@csn.ul.ie \
--cc=minchan.kim@gmail.com \
--cc=msb@chromium.org \
--cc=olofj@chromium.org \
--cc=riel@redhat.com \
--cc=wad@chromium.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;
as well as URLs for NNTP newsgroup(s).