From: Minchan Kim <minchan.kim@gmail.com>
To: Rik van Riel <riel@redhat.com>
Cc: Mandeep Singh Baines <msb@chromium.org>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Andrew Morton <akpm@linux-foundation.org>,
Mel Gorman <mel@csn.ul.ie>, 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, 4 Nov 2010 00:42:49 +0900 [thread overview]
Message-ID: <20101103154249.GA1779@barrios-desktop> (raw)
In-Reply-To: <4CD14A6F.4010109@redhat.com>
On Wed, Nov 03, 2010 at 07:41:35AM -0400, Rik van Riel wrote:
> On 11/02/2010 11:03 PM, Minchan Kim wrote:
>
> >It could.
> >But time based approach would be same, IMHO.
> >First of all, I don't want long latency of direct reclaim process.
> >It could affect response of foreground process directly.
> >
> >If VM limits the number of pages reclaimed per second, direct reclaim
> >process's latency will be affected. so we should avoid throttling in
> >direct reclaim path. Agree?
>
> The idea would be to not throttle the processes trying to
> reclaim page cache pages, but to only reclaim anonymous
> pages when the page cache pages are low (and occasionally
> a few page cache pages, say 128 a second).
Fair enough. Only anon reclaim is better than thrashing of code pages.
>
> If too many reclaimers come in when the page cache is
> low and no swap is available, we will OOM kill instead
> of stalling.
I understand why you use (file < pages_min).
We can keep the threshold small value. Otherwise,
we can see the many OOM question. "Why OOM happens although my system have enough
file LRU pages?"
>
> After all, the entire point of this patch would be to
> avoid minutes-long latencies in triggering the OOM
> killer.
I got your point. The patch's goal is not protect working set fully, but prevent
page cache thrashing in low file LRU.
It could make minutes-long latencies by reaching the OOM.
Okay. I will look into this idea.
Thanks for the good suggestion, Rik.
>
> --
> All rights reversed
--
Kind regards,
Minchan Kim
WARNING: multiple messages have this Message-ID (diff)
From: Minchan Kim <minchan.kim@gmail.com>
To: Rik van Riel <riel@redhat.com>
Cc: Mandeep Singh Baines <msb@chromium.org>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Andrew Morton <akpm@linux-foundation.org>,
Mel Gorman <mel@csn.ul.ie>, 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, 4 Nov 2010 00:42:49 +0900 [thread overview]
Message-ID: <20101103154249.GA1779@barrios-desktop> (raw)
In-Reply-To: <4CD14A6F.4010109@redhat.com>
On Wed, Nov 03, 2010 at 07:41:35AM -0400, Rik van Riel wrote:
> On 11/02/2010 11:03 PM, Minchan Kim wrote:
>
> >It could.
> >But time based approach would be same, IMHO.
> >First of all, I don't want long latency of direct reclaim process.
> >It could affect response of foreground process directly.
> >
> >If VM limits the number of pages reclaimed per second, direct reclaim
> >process's latency will be affected. so we should avoid throttling in
> >direct reclaim path. Agree?
>
> The idea would be to not throttle the processes trying to
> reclaim page cache pages, but to only reclaim anonymous
> pages when the page cache pages are low (and occasionally
> a few page cache pages, say 128 a second).
Fair enough. Only anon reclaim is better than thrashing of code pages.
>
> If too many reclaimers come in when the page cache is
> low and no swap is available, we will OOM kill instead
> of stalling.
I understand why you use (file < pages_min).
We can keep the threshold small value. Otherwise,
we can see the many OOM question. "Why OOM happens although my system have enough
file LRU pages?"
>
> After all, the entire point of this patch would be to
> avoid minutes-long latencies in triggering the OOM
> killer.
I got your point. The patch's goal is not protect working set fully, but prevent
page cache thrashing in low file LRU.
It could make minutes-long latencies by reaching the OOM.
Okay. I will look into this idea.
Thanks for the good suggestion, Rik.
>
> --
> All rights reversed
--
Kind regards,
Minchan Kim
--
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/ .
Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2010-11-03 15:43 UTC|newest]
Thread overview: 55+ 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 19:15 ` Mandeep Singh Baines
2010-10-28 20:10 ` Andrew Morton
2010-10-28 20:10 ` Andrew Morton
2010-10-28 22:03 ` Mandeep Singh Baines
2010-10-28 22:03 ` Mandeep Singh Baines
2010-10-28 23:28 ` Minchan Kim
2010-10-28 23:28 ` Minchan Kim
2010-10-28 23:29 ` Minchan Kim
2010-10-28 23:29 ` Minchan Kim
2010-10-29 0:04 ` KAMEZAWA Hiroyuki
2010-10-29 0:04 ` KAMEZAWA Hiroyuki
2010-10-29 0:28 ` Minchan Kim
2010-10-29 0:28 ` Minchan Kim
2010-10-28 21:30 ` Rik van Riel
2010-10-28 21:30 ` Rik van Riel
2010-10-28 22:13 ` Mandeep Singh Baines
2010-10-28 22:13 ` Mandeep Singh Baines
2010-11-01 7:05 ` KOSAKI Motohiro
2010-11-01 7:05 ` KOSAKI Motohiro
2010-11-01 18:24 ` Mandeep Singh Baines
2010-11-01 18:24 ` Mandeep Singh Baines
2010-11-01 18:50 ` Rik van Riel
2010-11-01 18:50 ` Rik van Riel
2010-11-01 19:43 ` Mandeep Singh Baines
2010-11-01 19:43 ` Mandeep Singh Baines
2010-11-02 3:11 ` Rik van Riel
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 2:00 ` Rik van Riel
2010-11-03 3:03 ` Minchan Kim
2010-11-03 3:03 ` Minchan Kim
2010-11-03 11:41 ` Rik van Riel
2010-11-03 11:41 ` Rik van Riel
2010-11-03 15:42 ` Minchan Kim [this message]
2010-11-03 15:42 ` Minchan Kim
2010-11-03 22:40 ` Mandeep Singh Baines
2010-11-03 22:40 ` Mandeep Singh Baines
2010-11-03 23:49 ` Minchan Kim
2010-11-03 23:49 ` Minchan Kim
2010-11-04 15:30 ` Rik van Riel
2010-11-04 15:30 ` Rik van Riel
2010-11-08 21:55 ` Mandeep Singh Baines
2010-11-08 21:55 ` Mandeep Singh Baines
2010-11-09 2:49 ` KOSAKI Motohiro
2010-11-09 2:49 ` KOSAKI Motohiro
2010-11-01 23:46 ` Minchan Kim
2010-11-01 23:46 ` Minchan Kim
2010-11-04 1:52 ` Mandeep Singh Baines
2010-11-04 1:52 ` Mandeep Singh Baines
2010-11-05 2:36 ` Minchan Kim
2010-11-05 2:36 ` Minchan Kim
2010-11-09 2:53 ` KOSAKI Motohiro
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=20101103154249.GA1779@barrios-desktop \
--to=minchan.kim@gmail.com \
--cc=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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.