From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> To: Mel Gorman <mel@csn.ul.ie> Cc: Christoph Hellwig <hch@infradead.org>, Rik van Riel <riel@redhat.com>, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, Dave Chinner <david@fromorbit.com>, Chris Mason <chris.mason@oracle.com>, Nick Piggin <npiggin@suse.de>, Johannes Weiner <hannes@cmpxchg.org>, Andrew Morton <akpm@linux-foundation.org> Subject: Re: [PATCH 12/12] vmscan: Do not writeback pages in direct reclaim Date: Wed, 16 Jun 2010 09:30:59 +0900 [thread overview] Message-ID: <20100616093059.7765574f.kamezawa.hiroyu@jp.fujitsu.com> (raw) In-Reply-To: <20100615135408.GJ26788@csn.ul.ie> On Tue, 15 Jun 2010 14:54:08 +0100 Mel Gorman <mel@csn.ul.ie> wrote: > On Tue, Jun 15, 2010 at 09:37:27AM -0400, Christoph Hellwig wrote: > > On Tue, Jun 15, 2010 at 09:34:18AM -0400, Rik van Riel wrote: > > > If direct reclaim can overflow the stack, so can direct > > > memcg reclaim. That means this patch does not solve the > > > stack overflow, while admitting that we do need the > > > ability to get specific pages flushed to disk from the > > > pageout code. > > > > Can you explain what the hell memcg reclaim is and why it needs > > to reclaim from random contexts? > > Kamezawa Hiroyuki has the full story here but here is a summary. > Thank you. > memcg is the Memory Controller cgroup > (Documentation/cgroups/memory.txt). It's intended for the control of the > amount of memory usable by a group of processes but its behaviour in > terms of reclaim differs from global reclaim. It has its own LRU lists > and kswapd operates on them. No, we don't use kswapd. But we have some hooks in kswapd for implementing soft-limit. Soft-limit is for giving a hint for kswapd "please reclaim memory from this memcg" when global memory exhausts and kswapd runs. What a memcg use when it his limit is just direct reclaim. (*) Justfing using a cpu by a kswapd because a memcg hits limit is difficult for me. So, I don't use kswapd until now. When direct-reclaim is used, cost-of-reclaim will be charged against a cpu cgroup which a thread belongs to. > What is surprising is that direct reclaim > for a process in the control group also does not operate within the > cgroup. Sorry, I can't understand .... > > Reclaim from a cgroup happens from the fault path. The new page is > "charged" to the cgroup. If it exceeds its allocated resources, some > pages within the group are reclaimed in a path that is similar to direct > reclaim except for its entry point. > yes. > So, memcg is not reclaiming from a random context, there is a limited > number of cases where a memcg is reclaiming and it is not expected to > overflow the stack. > I think so. Especially, we'll never see 1k stack use of select(). > > It seems everything that has a cg in it's name that I stumbled over > > lately seems to be some ugly wart.. > > > > The wart in this case is that the behaviour of page reclaim within a > memcg and globally differ a fair bit. > Sorry. But there has been very long story to reach current implementations. But don't worry, of memcg is not activated (not mounted), it doesn't affect the behavior of processes ;) But Hmm.. >[kamezawa@bluextal mmotm-2.6.35-0611]$ wc -l mm/memcontrol.c >4705 mm/memcontrol.c may need some diet :( Thanks, -Kame
WARNING: multiple messages have this Message-ID (diff)
From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> To: Mel Gorman <mel@csn.ul.ie> Cc: Christoph Hellwig <hch@infradead.org>, Rik van Riel <riel@redhat.com>, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, Dave Chinner <david@fromorbit.com>, Chris Mason <chris.mason@oracle.com>, Nick Piggin <npiggin@suse.de>, Johannes Weiner <hannes@cmpxchg.org>, Andrew Morton <akpm@linux-foundation.org> Subject: Re: [PATCH 12/12] vmscan: Do not writeback pages in direct reclaim Date: Wed, 16 Jun 2010 09:30:59 +0900 [thread overview] Message-ID: <20100616093059.7765574f.kamezawa.hiroyu@jp.fujitsu.com> (raw) In-Reply-To: <20100615135408.GJ26788@csn.ul.ie> On Tue, 15 Jun 2010 14:54:08 +0100 Mel Gorman <mel@csn.ul.ie> wrote: > On Tue, Jun 15, 2010 at 09:37:27AM -0400, Christoph Hellwig wrote: > > On Tue, Jun 15, 2010 at 09:34:18AM -0400, Rik van Riel wrote: > > > If direct reclaim can overflow the stack, so can direct > > > memcg reclaim. That means this patch does not solve the > > > stack overflow, while admitting that we do need the > > > ability to get specific pages flushed to disk from the > > > pageout code. > > > > Can you explain what the hell memcg reclaim is and why it needs > > to reclaim from random contexts? > > Kamezawa Hiroyuki has the full story here but here is a summary. > Thank you. > memcg is the Memory Controller cgroup > (Documentation/cgroups/memory.txt). It's intended for the control of the > amount of memory usable by a group of processes but its behaviour in > terms of reclaim differs from global reclaim. It has its own LRU lists > and kswapd operates on them. No, we don't use kswapd. But we have some hooks in kswapd for implementing soft-limit. Soft-limit is for giving a hint for kswapd "please reclaim memory from this memcg" when global memory exhausts and kswapd runs. What a memcg use when it his limit is just direct reclaim. (*) Justfing using a cpu by a kswapd because a memcg hits limit is difficult for me. So, I don't use kswapd until now. When direct-reclaim is used, cost-of-reclaim will be charged against a cpu cgroup which a thread belongs to. > What is surprising is that direct reclaim > for a process in the control group also does not operate within the > cgroup. Sorry, I can't understand .... > > Reclaim from a cgroup happens from the fault path. The new page is > "charged" to the cgroup. If it exceeds its allocated resources, some > pages within the group are reclaimed in a path that is similar to direct > reclaim except for its entry point. > yes. > So, memcg is not reclaiming from a random context, there is a limited > number of cases where a memcg is reclaiming and it is not expected to > overflow the stack. > I think so. Especially, we'll never see 1k stack use of select(). > > It seems everything that has a cg in it's name that I stumbled over > > lately seems to be some ugly wart.. > > > > The wart in this case is that the behaviour of page reclaim within a > memcg and globally differ a fair bit. > Sorry. But there has been very long story to reach current implementations. But don't worry, of memcg is not activated (not mounted), it doesn't affect the behavior of processes ;) But Hmm.. >[kamezawa@bluextal mmotm-2.6.35-0611]$ wc -l mm/memcontrol.c >4705 mm/memcontrol.c may need some diet :( Thanks, -Kame -- 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-06-16 0:35 UTC|newest] Thread overview: 198+ messages / expand[flat|nested] mbox.gz Atom feed top 2010-06-14 11:17 [PATCH 0/12] Avoid overflowing of stack during page reclaim V2 Mel Gorman 2010-06-14 11:17 ` Mel Gorman 2010-06-14 11:17 ` [PATCH 01/12] tracing, vmscan: Add trace events for kswapd wakeup, sleeping and direct reclaim Mel Gorman 2010-06-14 11:17 ` Mel Gorman 2010-06-14 15:45 ` Rik van Riel 2010-06-14 15:45 ` Rik van Riel 2010-06-14 21:01 ` Larry Woodman 2010-06-14 21:01 ` Larry Woodman 2010-06-14 11:17 ` [PATCH 02/12] tracing, vmscan: Add trace events for LRU page isolation Mel Gorman 2010-06-14 11:17 ` Mel Gorman 2010-06-14 16:47 ` Rik van Riel 2010-06-14 16:47 ` Rik van Riel 2010-06-14 21:02 ` Larry Woodman 2010-06-14 21:02 ` Larry Woodman 2010-06-14 11:17 ` [PATCH 03/12] tracing, vmscan: Add trace event when a page is written Mel Gorman 2010-06-14 11:17 ` Mel Gorman 2010-06-14 16:48 ` Rik van Riel 2010-06-14 16:48 ` Rik van Riel 2010-06-14 21:02 ` Larry Woodman 2010-06-14 21:02 ` Larry Woodman 2010-06-14 11:17 ` [PATCH 04/12] tracing, vmscan: Add a postprocessing script for reclaim-related ftrace events Mel Gorman 2010-06-14 11:17 ` Mel Gorman 2010-06-14 17:55 ` Rik van Riel 2010-06-14 17:55 ` Rik van Riel 2010-06-14 21:03 ` Larry Woodman 2010-06-14 21:03 ` Larry Woodman 2010-06-14 11:17 ` [PATCH 05/12] vmscan: kill prev_priority completely Mel Gorman 2010-06-14 11:17 ` Mel Gorman 2010-06-14 18:04 ` Rik van Riel 2010-06-14 18:04 ` Rik van Riel 2010-06-16 23:37 ` Andrew Morton 2010-06-16 23:37 ` Andrew Morton 2010-06-16 23:45 ` Rik van Riel 2010-06-16 23:45 ` Rik van Riel 2010-06-17 0:18 ` Andrew Morton 2010-06-17 0:18 ` Andrew Morton 2010-06-17 0:34 ` Rik van Riel 2010-06-17 0:34 ` Rik van Riel 2010-06-25 8:29 ` KOSAKI Motohiro 2010-06-25 8:29 ` KOSAKI Motohiro 2010-06-28 10:35 ` Mel Gorman 2010-06-28 10:35 ` Mel Gorman 2010-06-14 11:17 ` [PATCH 06/12] vmscan: simplify shrink_inactive_list() Mel Gorman 2010-06-14 11:17 ` Mel Gorman 2010-06-14 18:06 ` Rik van Riel 2010-06-14 18:06 ` Rik van Riel 2010-06-15 10:13 ` Mel Gorman 2010-06-15 10:13 ` Mel Gorman 2010-06-14 11:17 ` [PATCH 07/12] vmscan: Remove unnecessary temporary vars in do_try_to_free_pages Mel Gorman 2010-06-14 11:17 ` Mel Gorman 2010-06-14 18:14 ` Rik van Riel 2010-06-14 18:14 ` Rik van Riel 2010-06-14 11:17 ` [PATCH 08/12] vmscan: Setup pagevec as late as possible in shrink_inactive_list() Mel Gorman 2010-06-14 11:17 ` Mel Gorman 2010-06-14 18:59 ` Rik van Riel 2010-06-14 18:59 ` Rik van Riel 2010-06-15 10:47 ` Christoph Hellwig 2010-06-15 10:47 ` Christoph Hellwig 2010-06-15 15:56 ` Mel Gorman 2010-06-15 15:56 ` Mel Gorman 2010-06-16 23:43 ` Andrew Morton 2010-06-16 23:43 ` Andrew Morton 2010-06-17 10:30 ` Mel Gorman 2010-06-17 10:30 ` Mel Gorman 2010-06-14 11:17 ` [PATCH 09/12] vmscan: Setup pagevec as late as possible in shrink_page_list() Mel Gorman 2010-06-14 11:17 ` Mel Gorman 2010-06-14 19:24 ` Rik van Riel 2010-06-14 19:24 ` Rik van Riel 2010-06-16 23:48 ` Andrew Morton 2010-06-16 23:48 ` Andrew Morton 2010-06-17 10:46 ` Mel Gorman 2010-06-17 10:46 ` Mel Gorman 2010-06-14 11:17 ` [PATCH 10/12] vmscan: Update isolated page counters outside of main path in shrink_inactive_list() Mel Gorman 2010-06-14 11:17 ` Mel Gorman 2010-06-14 19:42 ` Rik van Riel 2010-06-14 19:42 ` Rik van Riel 2010-06-14 11:17 ` [PATCH 11/12] vmscan: Write out dirty pages in batch Mel Gorman 2010-06-14 11:17 ` Mel Gorman 2010-06-14 21:13 ` Rik van Riel 2010-06-14 21:13 ` Rik van Riel 2010-06-15 10:18 ` Mel Gorman 2010-06-15 10:18 ` Mel Gorman 2010-06-14 23:11 ` Dave Chinner 2010-06-14 23:11 ` Dave Chinner 2010-06-14 23:21 ` Andrew Morton 2010-06-14 23:21 ` Andrew Morton 2010-06-15 0:39 ` Dave Chinner 2010-06-15 0:39 ` Dave Chinner 2010-06-15 1:16 ` Rik van Riel 2010-06-15 1:16 ` Rik van Riel 2010-06-15 1:45 ` Andrew Morton 2010-06-15 1:45 ` Andrew Morton 2010-06-15 4:08 ` Rik van Riel 2010-06-15 4:08 ` Rik van Riel 2010-06-15 4:37 ` Andrew Morton 2010-06-15 4:37 ` Andrew Morton 2010-06-15 5:12 ` Nick Piggin 2010-06-15 5:12 ` Nick Piggin 2010-06-15 5:43 ` [patch] mm: vmscan fix mapping use after free Nick Piggin 2010-06-15 5:43 ` Nick Piggin 2010-06-15 13:23 ` Mel Gorman 2010-06-15 13:23 ` Mel Gorman 2010-06-15 11:01 ` [PATCH 11/12] vmscan: Write out dirty pages in batch Christoph Hellwig 2010-06-15 11:01 ` Christoph Hellwig 2010-06-15 13:32 ` Rik van Riel 2010-06-15 13:32 ` Rik van Riel 2010-06-15 1:39 ` Andrew Morton 2010-06-15 1:39 ` Andrew Morton 2010-06-15 3:20 ` Dave Chinner 2010-06-15 3:20 ` Dave Chinner 2010-06-15 4:15 ` Andrew Morton 2010-06-15 4:15 ` Andrew Morton 2010-06-15 6:36 ` Dave Chinner 2010-06-15 6:36 ` Dave Chinner 2010-06-15 10:28 ` Evgeniy Polyakov 2010-06-15 10:28 ` Evgeniy Polyakov 2010-06-15 10:55 ` Nick Piggin 2010-06-15 10:55 ` Nick Piggin 2010-06-15 11:10 ` Christoph Hellwig 2010-06-15 11:10 ` Christoph Hellwig 2010-06-15 11:20 ` Nick Piggin 2010-06-15 11:20 ` Nick Piggin 2010-06-15 23:20 ` Dave Chinner 2010-06-15 23:20 ` Dave Chinner 2010-06-16 6:04 ` Nick Piggin 2010-06-16 6:04 ` Nick Piggin 2010-06-15 11:08 ` Christoph Hellwig 2010-06-15 11:08 ` Christoph Hellwig 2010-06-15 11:43 ` Mel Gorman 2010-06-15 11:43 ` Mel Gorman 2010-06-15 13:07 ` tytso 2010-06-15 13:07 ` tytso 2010-06-15 15:44 ` Mel Gorman 2010-06-15 15:44 ` Mel Gorman 2010-06-15 10:57 ` Christoph Hellwig 2010-06-15 10:57 ` Christoph Hellwig 2010-06-15 10:53 ` Christoph Hellwig 2010-06-15 10:53 ` Christoph Hellwig 2010-06-15 11:11 ` Mel Gorman 2010-06-15 11:11 ` Mel Gorman 2010-06-15 11:13 ` Nick Piggin 2010-06-15 11:13 ` Nick Piggin 2010-06-14 11:17 ` [PATCH 12/12] vmscan: Do not writeback pages in direct reclaim Mel Gorman 2010-06-14 11:17 ` Mel Gorman 2010-06-14 21:55 ` Rik van Riel 2010-06-14 21:55 ` Rik van Riel 2010-06-15 11:45 ` Mel Gorman 2010-06-15 11:45 ` Mel Gorman 2010-06-15 13:34 ` Rik van Riel 2010-06-15 13:34 ` Rik van Riel 2010-06-15 13:37 ` Christoph Hellwig 2010-06-15 13:37 ` Christoph Hellwig 2010-06-15 13:54 ` Mel Gorman 2010-06-15 13:54 ` Mel Gorman 2010-06-16 0:30 ` KAMEZAWA Hiroyuki [this message] 2010-06-16 0:30 ` KAMEZAWA Hiroyuki 2010-06-15 14:02 ` Rik van Riel 2010-06-15 14:02 ` Rik van Riel 2010-06-15 13:59 ` Mel Gorman 2010-06-15 13:59 ` Mel Gorman 2010-06-15 14:04 ` Rik van Riel 2010-06-15 14:04 ` Rik van Riel 2010-06-15 14:16 ` Mel Gorman 2010-06-15 14:16 ` Mel Gorman 2010-06-16 0:17 ` KAMEZAWA Hiroyuki 2010-06-16 0:17 ` KAMEZAWA Hiroyuki 2010-06-16 0:29 ` Rik van Riel 2010-06-16 0:29 ` Rik van Riel 2010-06-16 0:39 ` KAMEZAWA Hiroyuki 2010-06-16 0:39 ` KAMEZAWA Hiroyuki 2010-06-16 0:53 ` Rik van Riel 2010-06-16 0:53 ` Rik van Riel 2010-06-16 1:40 ` KAMEZAWA Hiroyuki 2010-06-16 1:40 ` KAMEZAWA Hiroyuki 2010-06-16 2:20 ` KAMEZAWA Hiroyuki 2010-06-16 2:20 ` KAMEZAWA Hiroyuki 2010-06-16 5:11 ` Christoph Hellwig 2010-06-16 5:11 ` Christoph Hellwig 2010-06-16 10:51 ` Jens Axboe 2010-06-16 10:51 ` Jens Axboe 2010-06-16 5:07 ` Christoph Hellwig 2010-06-16 5:07 ` Christoph Hellwig 2010-06-16 5:06 ` Christoph Hellwig 2010-06-16 5:06 ` Christoph Hellwig 2010-06-17 0:25 ` KAMEZAWA Hiroyuki 2010-06-17 0:25 ` KAMEZAWA Hiroyuki 2010-06-17 6:16 ` Christoph Hellwig 2010-06-17 6:16 ` Christoph Hellwig 2010-06-17 6:23 ` KAMEZAWA Hiroyuki 2010-06-17 6:23 ` KAMEZAWA Hiroyuki 2010-06-14 15:10 ` [PATCH 0/12] Avoid overflowing of stack during page reclaim V2 Christoph Hellwig 2010-06-14 15:10 ` Christoph Hellwig 2010-06-15 11:45 ` Mel Gorman 2010-06-15 11:45 ` Mel Gorman 2010-06-15 0:08 ` KAMEZAWA Hiroyuki 2010-06-15 0:08 ` KAMEZAWA Hiroyuki 2010-06-15 11:49 ` Mel Gorman 2010-06-15 11:49 ` Mel Gorman
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=20100616093059.7765574f.kamezawa.hiroyu@jp.fujitsu.com \ --to=kamezawa.hiroyu@jp.fujitsu.com \ --cc=akpm@linux-foundation.org \ --cc=chris.mason@oracle.com \ --cc=david@fromorbit.com \ --cc=hannes@cmpxchg.org \ --cc=hch@infradead.org \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mel@csn.ul.ie \ --cc=npiggin@suse.de \ --cc=riel@redhat.com \ /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.