From: Peter Zijlstra <peterz@infradead.org>
To: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
linux-mm <linux-mm@kvack.org>,
Andrew Morton <akpm@linux-foundation.org>,
Nick Piggin <nickpiggin@yahoo.com.au>,
Ingo Molnar <mingo@elte.hu>
Subject: Re: [PATCH] mm, lockdep: annotate reclaim context to zone reclaim too
Date: Sat, 02 Jan 2010 11:46:06 +0100 [thread overview]
Message-ID: <1262429166.32223.32.camel@laptop> (raw)
In-Reply-To: <2f11576a1001012121o4f09d30n6dba925e74099da1@mail.gmail.com>
On Sat, 2010-01-02 at 14:21 +0900, KOSAKI Motohiro wrote:
> 2010/1/2 Peter Zijlstra <peterz@infradead.org>:
> > On Fri, 2010-01-01 at 18:45 +0900, KOSAKI Motohiro wrote:
> >> Commit cf40bd16fd (lockdep: annotate reclaim context) introduced reclaim
> >> context annotation. But it didn't annotate zone reclaim. This patch do it.
> >
> > And yet you didn't CC anyone involved in that patch, nor explain why you
> > think it necessary, massive FAIL.
> >
> > The lockdep annotations cover all of kswapd() and direct reclaim through
> > __alloc_pages_direct_reclaim(). So why would you need an explicit
> > annotation in __zone_reclaim()?
>
> Thanks CCing. The point is zone-reclaim doesn't use
> __alloc_pages_direct_reclaim.
> current call graph is
>
> __alloc_pages_nodemask
> get_page_from_freelist
> zone_reclaim()
> __alloc_pages_slowpath
> __alloc_pages_direct_reclaim
> try_to_free_pages
>
> Actually, if zone_reclaim_mode=1, VM never call
> __alloc_pages_direct_reclaim in usual VM pressure.
> Thus I think zone-reclaim should be annotated explicitly too.
> I know almost user don't use zone reclaim mode. but explicit
> annotation doesn't have any demerit, I think.
Just be aware that the annotation isn't recursive, I'd have to trace all
calls to __zone_reclaim, but if kswapd were ever to call it you'd just
wrecked things by getting lockdep_clear_current_reclaim_state() called.
So just make sure you don't shorten the existing notations by adding it
here. Other than that it seems ok.
WARNING: multiple messages have this Message-ID (diff)
From: Peter Zijlstra <peterz@infradead.org>
To: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
linux-mm <linux-mm@kvack.org>,
Andrew Morton <akpm@linux-foundation.org>,
Nick Piggin <nickpiggin@yahoo.com.au>,
Ingo Molnar <mingo@elte.hu>
Subject: Re: [PATCH] mm, lockdep: annotate reclaim context to zone reclaim too
Date: Sat, 02 Jan 2010 11:46:06 +0100 [thread overview]
Message-ID: <1262429166.32223.32.camel@laptop> (raw)
In-Reply-To: <2f11576a1001012121o4f09d30n6dba925e74099da1@mail.gmail.com>
On Sat, 2010-01-02 at 14:21 +0900, KOSAKI Motohiro wrote:
> 2010/1/2 Peter Zijlstra <peterz@infradead.org>:
> > On Fri, 2010-01-01 at 18:45 +0900, KOSAKI Motohiro wrote:
> >> Commit cf40bd16fd (lockdep: annotate reclaim context) introduced reclaim
> >> context annotation. But it didn't annotate zone reclaim. This patch do it.
> >
> > And yet you didn't CC anyone involved in that patch, nor explain why you
> > think it necessary, massive FAIL.
> >
> > The lockdep annotations cover all of kswapd() and direct reclaim through
> > __alloc_pages_direct_reclaim(). So why would you need an explicit
> > annotation in __zone_reclaim()?
>
> Thanks CCing. The point is zone-reclaim doesn't use
> __alloc_pages_direct_reclaim.
> current call graph is
>
> __alloc_pages_nodemask
> get_page_from_freelist
> zone_reclaim()
> __alloc_pages_slowpath
> __alloc_pages_direct_reclaim
> try_to_free_pages
>
> Actually, if zone_reclaim_mode=1, VM never call
> __alloc_pages_direct_reclaim in usual VM pressure.
> Thus I think zone-reclaim should be annotated explicitly too.
> I know almost user don't use zone reclaim mode. but explicit
> annotation doesn't have any demerit, I think.
Just be aware that the annotation isn't recursive, I'd have to trace all
calls to __zone_reclaim, but if kswapd were ever to call it you'd just
wrecked things by getting lockdep_clear_current_reclaim_state() called.
So just make sure you don't shorten the existing notations by adding it
here. Other than that it seems ok.
--
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-01-02 10:47 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-01 9:45 [PATCH] mm, lockdep: annotate reclaim context to zone reclaim too KOSAKI Motohiro
2010-01-01 9:45 ` KOSAKI Motohiro
2010-01-01 23:19 ` Peter Zijlstra
2010-01-01 23:19 ` Peter Zijlstra
2010-01-02 5:21 ` KOSAKI Motohiro
2010-01-02 5:21 ` KOSAKI Motohiro
2010-01-02 10:46 ` Peter Zijlstra [this message]
2010-01-02 10:46 ` Peter Zijlstra
2010-01-02 13:29 ` KOSAKI Motohiro
2010-01-02 13:29 ` KOSAKI Motohiro
2010-01-02 14:45 ` Peter Zijlstra
2010-01-02 14:45 ` Peter Zijlstra
2010-01-02 15:09 ` KOSAKI Motohiro
2010-01-02 15:09 ` 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=1262429166.32223.32.camel@laptop \
--to=peterz@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mingo@elte.hu \
--cc=nickpiggin@yahoo.com.au \
/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.