From: Dave Chinner <david@fromorbit.com> To: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Cc: Mel Gorman <mel@csn.ul.ie>, Chris Mason <chris.mason@oracle.com>, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH] mm: disallow direct reclaim page writeback Date: Thu, 15 Apr 2010 18:54:20 +1000 [thread overview] Message-ID: <20100415085420.GT2493@dastard> (raw) In-Reply-To: <20100415152816.D18C.A69D9226@jp.fujitsu.com> On Thu, Apr 15, 2010 at 03:35:14PM +0900, KOSAKI Motohiro wrote: > > On Thu, Apr 15, 2010 at 01:09:01PM +0900, KOSAKI Motohiro wrote: > > > Hi > > > > > > > How about this? For now, we stop direct reclaim from doing writeback > > > > only on order zero allocations, but allow it for higher order > > > > allocations. That will prevent the majority of situations where > > > > direct reclaim blows the stack and interferes with background > > > > writeout, but won't cause lumpy reclaim to change behaviour. > > > > This reduces the scope of impact and hence testing and validation > > > > the needs to be done. > > > > > > Tend to agree. but I would proposed slightly different algorithm for > > > avoind incorrect oom. > > > > > > for high order allocation > > > allow to use lumpy reclaim and pageout() for both kswapd and direct reclaim > > > > SO same as current. > > Yes. as same as you propsed. > > > > > > for low order allocation > > > - kswapd: always delegate io to flusher thread > > > - direct reclaim: delegate io to flusher thread only if vm pressure is low > > > > IMO, this really doesn't fix either of the problems - the bad IO > > patterns nor the stack usage. All it will take is a bit more memory > > pressure to trigger stack and IO problems, and the user reporting the > > problems is generating an awful lot of memory pressure... > > This patch doesn't care stack usage. because > - again, I think all stack eater shold be diet. Agreed (again), but we've already come to the conclusion that a stack diet is not enough. > - under allowing lumpy reclaim world, only deny low order reclaim > doesn't solve anything. Yes, I suggested it *as a first step*, not as the end goal. Your patches don't reach the first step which is fixing the reported stack problem for order-0 allocations... > Please don't forget priority=0 recliam failure incvoke OOM-killer. > I don't imagine anyone want it. Given that I haven't been able to trigger OOM without writeback from direct reclaim so far (*) I'm not finding any evidence that it is a problem or that there are regressions. I want to be able to say that this change has no known regressions. I want to find the regression and work to fix them, but without test cases there's no way I can do this. This is what I'm getting frustrated about - I want to fix this problem once and for all, but I can't find out what I need to do to robustly test such a change so we can have a high degree of confidence that it doesn't introduce major regressions. Can anyone help here? (*) except in one case I've already described where it mananged to allocate enough huge pages to starve the system of order zero pages, which is what I asked it to do. > And, Which IO workload trigger <6 priority vmscan? You're asking me? I've been asking you for workloads that wind up reclaim priority.... :/ All I can say is that the most common trigger I see for OOM is copying a large file on a busy system that is running off a single spindle. When that happens on my laptop I walk away and get a cup of coffee when that happens and when I come back I pick up all the broken bits the OOM killer left behind..... Cheers, Dave. -- Dave Chinner david@fromorbit.com
WARNING: multiple messages have this Message-ID (diff)
From: Dave Chinner <david@fromorbit.com> To: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Cc: Mel Gorman <mel@csn.ul.ie>, Chris Mason <chris.mason@oracle.com>, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH] mm: disallow direct reclaim page writeback Date: Thu, 15 Apr 2010 18:54:20 +1000 [thread overview] Message-ID: <20100415085420.GT2493@dastard> (raw) In-Reply-To: <20100415152816.D18C.A69D9226@jp.fujitsu.com> On Thu, Apr 15, 2010 at 03:35:14PM +0900, KOSAKI Motohiro wrote: > > On Thu, Apr 15, 2010 at 01:09:01PM +0900, KOSAKI Motohiro wrote: > > > Hi > > > > > > > How about this? For now, we stop direct reclaim from doing writeback > > > > only on order zero allocations, but allow it for higher order > > > > allocations. That will prevent the majority of situations where > > > > direct reclaim blows the stack and interferes with background > > > > writeout, but won't cause lumpy reclaim to change behaviour. > > > > This reduces the scope of impact and hence testing and validation > > > > the needs to be done. > > > > > > Tend to agree. but I would proposed slightly different algorithm for > > > avoind incorrect oom. > > > > > > for high order allocation > > > allow to use lumpy reclaim and pageout() for both kswapd and direct reclaim > > > > SO same as current. > > Yes. as same as you propsed. > > > > > > for low order allocation > > > - kswapd: always delegate io to flusher thread > > > - direct reclaim: delegate io to flusher thread only if vm pressure is low > > > > IMO, this really doesn't fix either of the problems - the bad IO > > patterns nor the stack usage. All it will take is a bit more memory > > pressure to trigger stack and IO problems, and the user reporting the > > problems is generating an awful lot of memory pressure... > > This patch doesn't care stack usage. because > - again, I think all stack eater shold be diet. Agreed (again), but we've already come to the conclusion that a stack diet is not enough. > - under allowing lumpy reclaim world, only deny low order reclaim > doesn't solve anything. Yes, I suggested it *as a first step*, not as the end goal. Your patches don't reach the first step which is fixing the reported stack problem for order-0 allocations... > Please don't forget priority=0 recliam failure incvoke OOM-killer. > I don't imagine anyone want it. Given that I haven't been able to trigger OOM without writeback from direct reclaim so far (*) I'm not finding any evidence that it is a problem or that there are regressions. I want to be able to say that this change has no known regressions. I want to find the regression and work to fix them, but without test cases there's no way I can do this. This is what I'm getting frustrated about - I want to fix this problem once and for all, but I can't find out what I need to do to robustly test such a change so we can have a high degree of confidence that it doesn't introduce major regressions. Can anyone help here? (*) except in one case I've already described where it mananged to allocate enough huge pages to starve the system of order zero pages, which is what I asked it to do. > And, Which IO workload trigger <6 priority vmscan? You're asking me? I've been asking you for workloads that wind up reclaim priority.... :/ All I can say is that the most common trigger I see for OOM is copying a large file on a busy system that is running off a single spindle. When that happens on my laptop I walk away and get a cup of coffee when that happens and when I come back I pick up all the broken bits the OOM killer left behind..... Cheers, Dave. -- Dave Chinner david@fromorbit.com -- 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-04-15 8:54 UTC|newest] Thread overview: 248+ messages / expand[flat|nested] mbox.gz Atom feed top 2010-04-13 0:17 [PATCH] mm: disallow direct reclaim page writeback Dave Chinner 2010-04-13 0:17 ` Dave Chinner 2010-04-13 8:31 ` KOSAKI Motohiro 2010-04-13 8:31 ` KOSAKI Motohiro 2010-04-13 10:29 ` Dave Chinner 2010-04-13 10:29 ` Dave Chinner 2010-04-13 11:39 ` KOSAKI Motohiro 2010-04-13 11:39 ` KOSAKI Motohiro 2010-04-13 14:36 ` Dave Chinner 2010-04-13 14:36 ` Dave Chinner 2010-04-14 3:12 ` Dave Chinner 2010-04-14 3:12 ` Dave Chinner 2010-04-14 6:52 ` KOSAKI Motohiro 2010-04-14 6:52 ` KOSAKI Motohiro 2010-04-15 1:56 ` Dave Chinner 2010-04-15 1:56 ` Dave Chinner 2010-04-14 6:52 ` KOSAKI Motohiro 2010-04-14 6:52 ` KOSAKI Motohiro 2010-04-14 7:36 ` Dave Chinner 2010-04-14 7:36 ` Dave Chinner 2010-04-13 9:58 ` Mel Gorman 2010-04-13 9:58 ` Mel Gorman 2010-04-13 11:19 ` Dave Chinner 2010-04-13 11:19 ` Dave Chinner 2010-04-13 19:34 ` Mel Gorman 2010-04-13 19:34 ` Mel Gorman 2010-04-13 20:20 ` Chris Mason 2010-04-13 20:20 ` Chris Mason 2010-04-14 1:40 ` Dave Chinner 2010-04-14 1:40 ` Dave Chinner 2010-04-14 4:59 ` KAMEZAWA Hiroyuki 2010-04-14 4:59 ` KAMEZAWA Hiroyuki 2010-04-14 5:41 ` Dave Chinner 2010-04-14 5:41 ` Dave Chinner 2010-04-14 5:54 ` KOSAKI Motohiro 2010-04-14 5:54 ` KOSAKI Motohiro 2010-04-14 6:13 ` Minchan Kim 2010-04-14 7:19 ` Minchan Kim 2010-04-14 7:19 ` Minchan Kim 2010-04-14 9:42 ` KAMEZAWA Hiroyuki 2010-04-14 9:42 ` KAMEZAWA Hiroyuki 2010-04-14 9:42 ` KAMEZAWA Hiroyuki 2010-04-14 10:01 ` Minchan Kim 2010-04-14 10:01 ` Minchan Kim 2010-04-14 10:07 ` Mel Gorman 2010-04-14 10:07 ` Mel Gorman 2010-04-14 10:07 ` Mel Gorman 2010-04-14 10:16 ` Minchan Kim 2010-04-14 10:16 ` Minchan Kim 2010-04-14 7:06 ` Dave Chinner 2010-04-14 7:06 ` Dave Chinner 2010-04-14 6:52 ` KOSAKI Motohiro 2010-04-14 6:52 ` KOSAKI Motohiro 2010-04-14 7:28 ` Dave Chinner 2010-04-14 7:28 ` Dave Chinner 2010-04-14 8:51 ` Mel Gorman 2010-04-14 8:51 ` Mel Gorman 2010-04-15 1:34 ` Dave Chinner 2010-04-15 1:34 ` Dave Chinner 2010-04-15 1:34 ` Dave Chinner 2010-04-15 4:09 ` KOSAKI Motohiro 2010-04-15 4:09 ` KOSAKI Motohiro 2010-04-15 4:11 ` [PATCH 1/4] vmscan: delegate pageout io to flusher thread if current is kswapd KOSAKI Motohiro 2010-04-15 4:11 ` KOSAKI Motohiro 2010-04-15 4:11 ` KOSAKI Motohiro 2010-04-15 8:05 ` Suleiman Souhlal 2010-04-15 8:05 ` Suleiman Souhlal 2010-04-15 8:17 ` KOSAKI Motohiro 2010-04-15 8:17 ` KOSAKI Motohiro 2010-04-15 8:26 ` KOSAKI Motohiro 2010-04-15 8:26 ` KOSAKI Motohiro 2010-04-15 10:30 ` Johannes Weiner 2010-04-15 10:30 ` Johannes Weiner 2010-04-15 17:24 ` Suleiman Souhlal 2010-04-15 17:24 ` Suleiman Souhlal 2010-04-20 2:56 ` Ying Han 2010-04-20 2:56 ` Ying Han 2010-04-15 9:32 ` Dave Chinner 2010-04-15 9:32 ` Dave Chinner 2010-04-15 9:41 ` KOSAKI Motohiro 2010-04-15 9:41 ` KOSAKI Motohiro 2010-04-15 17:27 ` Suleiman Souhlal 2010-04-15 17:27 ` Suleiman Souhlal 2010-04-15 23:33 ` Dave Chinner 2010-04-15 23:33 ` Dave Chinner 2010-04-15 23:41 ` Suleiman Souhlal 2010-04-15 23:41 ` Suleiman Souhlal 2010-04-16 9:50 ` Alan Cox 2010-04-16 9:50 ` Alan Cox 2010-04-17 3:06 ` Dave Chinner 2010-04-17 3:06 ` Dave Chinner 2010-04-15 8:18 ` KOSAKI Motohiro 2010-04-15 8:18 ` KOSAKI Motohiro 2010-04-15 8:18 ` KOSAKI Motohiro 2010-04-15 10:31 ` Mel Gorman 2010-04-15 10:31 ` Mel Gorman 2010-04-15 11:26 ` KOSAKI Motohiro 2010-04-15 11:26 ` KOSAKI Motohiro 2010-04-15 4:13 ` [PATCH 2/4] vmscan: kill prev_priority completely KOSAKI Motohiro 2010-04-15 4:13 ` KOSAKI Motohiro 2010-04-15 4:13 ` KOSAKI Motohiro 2010-04-15 4:14 ` [PATCH 3/4] vmscan: move priority variable into scan_control KOSAKI Motohiro 2010-04-15 4:14 ` KOSAKI Motohiro 2010-04-15 4:14 ` KOSAKI Motohiro 2010-04-15 4:15 ` [PATCH 4/4] vmscan: delegate page cleaning io to flusher thread if VM pressure is low KOSAKI Motohiro 2010-04-15 4:15 ` KOSAKI Motohiro 2010-04-15 4:15 ` KOSAKI Motohiro 2010-04-15 4:35 ` [PATCH] mm: disallow direct reclaim page writeback KOSAKI Motohiro 2010-04-15 4:35 ` KOSAKI Motohiro 2010-04-15 6:32 ` Dave Chinner 2010-04-15 6:32 ` Dave Chinner 2010-04-15 6:44 ` KOSAKI Motohiro 2010-04-15 6:44 ` KOSAKI Motohiro 2010-04-15 6:58 ` Dave Chinner 2010-04-15 6:58 ` Dave Chinner 2010-04-15 6:20 ` Dave Chinner 2010-04-15 6:20 ` Dave Chinner 2010-04-15 6:35 ` KOSAKI Motohiro 2010-04-15 6:35 ` KOSAKI Motohiro 2010-04-15 8:54 ` Dave Chinner [this message] 2010-04-15 8:54 ` Dave Chinner 2010-04-15 10:21 ` KOSAKI Motohiro 2010-04-15 10:21 ` KOSAKI Motohiro 2010-04-15 10:23 ` [PATCH 1/4] vmscan: simplify shrink_inactive_list() KOSAKI Motohiro 2010-04-15 10:23 ` KOSAKI Motohiro 2010-04-15 13:15 ` Mel Gorman 2010-04-15 13:15 ` Mel Gorman 2010-04-15 15:01 ` Andi Kleen 2010-04-15 15:01 ` Andi Kleen 2010-04-15 15:01 ` Andi Kleen 2010-04-15 15:44 ` Mel Gorman 2010-04-15 15:44 ` Mel Gorman 2010-04-15 16:54 ` Andi Kleen 2010-04-15 16:54 ` Andi Kleen 2010-04-15 23:40 ` Dave Chinner 2010-04-15 23:40 ` Dave Chinner 2010-04-16 7:13 ` Andi Kleen 2010-04-16 7:13 ` Andi Kleen 2010-04-16 14:57 ` Mel Gorman 2010-04-16 14:57 ` Mel Gorman 2010-04-17 2:37 ` Dave Chinner 2010-04-17 2:37 ` Dave Chinner 2010-04-16 14:55 ` Mel Gorman 2010-04-16 14:55 ` Mel Gorman 2010-04-15 18:22 ` Valdis.Kletnieks 2010-04-16 9:39 ` Mel Gorman 2010-04-16 9:39 ` Mel Gorman 2010-04-15 10:24 ` [PATCH 2/4] [cleanup] mm: introduce free_pages_prepare KOSAKI Motohiro 2010-04-15 10:24 ` KOSAKI Motohiro 2010-04-15 10:24 ` KOSAKI Motohiro 2010-04-15 13:33 ` Mel Gorman 2010-04-15 13:33 ` Mel Gorman 2010-04-15 10:24 ` [PATCH 3/4] mm: introduce free_pages_bulk KOSAKI Motohiro 2010-04-15 10:24 ` KOSAKI Motohiro 2010-04-15 10:24 ` KOSAKI Motohiro 2010-04-15 13:46 ` Mel Gorman 2010-04-15 13:46 ` Mel Gorman 2010-04-15 10:26 ` [PATCH 4/4] vmscan: replace the pagevec in shrink_inactive_list() with list KOSAKI Motohiro 2010-04-15 10:26 ` KOSAKI Motohiro 2010-04-15 10:28 ` [PATCH] mm: disallow direct reclaim page writeback Mel Gorman 2010-04-15 10:28 ` Mel Gorman 2010-04-15 13:42 ` Chris Mason 2010-04-15 13:42 ` Chris Mason 2010-04-15 17:50 ` tytso 2010-04-15 17:50 ` tytso 2010-04-15 17:50 ` tytso 2010-04-16 15:05 ` Mel Gorman 2010-04-16 15:05 ` Mel Gorman 2010-04-19 15:15 ` Mel Gorman 2010-04-19 15:15 ` Mel Gorman 2010-04-19 15:15 ` Mel Gorman 2010-04-19 17:38 ` Chris Mason 2010-04-16 15:05 ` Mel Gorman 2010-04-16 4:14 ` Dave Chinner 2010-04-16 4:14 ` Dave Chinner 2010-04-16 15:14 ` Mel Gorman 2010-04-16 15:14 ` Mel Gorman 2010-04-18 0:32 ` Andrew Morton 2010-04-18 0:32 ` Andrew Morton 2010-04-18 19:05 ` Christoph Hellwig 2010-04-18 19:05 ` Christoph Hellwig 2010-04-18 16:31 ` Andrew Morton 2010-04-18 16:31 ` Andrew Morton 2010-04-18 19:35 ` Christoph Hellwig 2010-04-18 19:35 ` Christoph Hellwig 2010-04-18 19:11 ` Sorin Faibish 2010-04-18 19:11 ` Sorin Faibish 2010-04-18 19:11 ` Sorin Faibish 2010-04-18 19:10 ` Sorin Faibish 2010-04-18 19:10 ` Sorin Faibish 2010-04-18 19:10 ` Sorin Faibish 2010-04-18 21:30 ` James Bottomley 2010-04-18 21:30 ` James Bottomley 2010-04-18 23:34 ` Sorin Faibish 2010-04-18 23:34 ` Sorin Faibish 2010-04-18 23:34 ` Sorin Faibish 2010-04-19 3:08 ` tytso 2010-04-19 3:08 ` tytso 2010-04-19 0:35 ` Dave Chinner 2010-04-19 0:35 ` Dave Chinner 2010-04-19 0:49 ` Arjan van de Ven 2010-04-19 0:49 ` Arjan van de Ven 2010-04-19 1:08 ` Dave Chinner 2010-04-19 1:08 ` Dave Chinner 2010-04-19 4:32 ` Arjan van de Ven 2010-04-19 4:32 ` Arjan van de Ven 2010-04-19 15:20 ` Mel Gorman 2010-04-19 15:20 ` Mel Gorman 2010-04-23 1:06 ` Dave Chinner 2010-04-23 1:06 ` Dave Chinner 2010-04-23 10:50 ` Mel Gorman 2010-04-23 10:50 ` Mel Gorman 2010-04-15 14:57 ` Andi Kleen 2010-04-15 14:57 ` Andi Kleen 2010-04-15 2:37 ` Johannes Weiner 2010-04-15 2:37 ` Johannes Weiner 2010-04-15 2:43 ` KOSAKI Motohiro 2010-04-15 2:43 ` KOSAKI Motohiro 2010-04-16 23:56 ` Johannes Weiner 2010-04-16 23:56 ` Johannes Weiner 2010-04-14 6:52 ` KOSAKI Motohiro 2010-04-14 6:52 ` KOSAKI Motohiro 2010-04-14 10:06 ` Andi Kleen 2010-04-14 10:06 ` Andi Kleen 2010-04-14 10:06 ` Andi Kleen 2010-04-14 11:20 ` Chris Mason 2010-04-14 11:20 ` Chris Mason 2010-04-14 12:15 ` Andi Kleen 2010-04-14 12:15 ` Andi Kleen 2010-04-14 12:15 ` Andi Kleen 2010-04-14 12:32 ` Alan Cox 2010-04-14 12:32 ` Alan Cox 2010-04-14 12:34 ` Andi Kleen 2010-04-14 12:34 ` Andi Kleen 2010-04-14 13:23 ` Mel Gorman 2010-04-14 13:23 ` Mel Gorman 2010-04-14 14:07 ` Chris Mason 2010-04-14 14:07 ` Chris Mason 2010-04-14 0:24 ` Minchan Kim 2010-04-14 0:24 ` Minchan Kim 2010-04-14 4:44 ` Dave Chinner 2010-04-14 4:44 ` Dave Chinner 2010-04-14 7:54 ` Minchan Kim 2010-04-14 7:54 ` Minchan Kim 2010-04-16 1:13 ` KAMEZAWA Hiroyuki 2010-04-16 1:13 ` KAMEZAWA Hiroyuki 2010-04-16 4:18 ` KAMEZAWA Hiroyuki 2010-04-16 4:18 ` KAMEZAWA Hiroyuki
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=20100415085420.GT2493@dastard \ --to=david@fromorbit.com \ --cc=chris.mason@oracle.com \ --cc=kosaki.motohiro@jp.fujitsu.com \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mel@csn.ul.ie \ /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: linkBe 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.