From: "Yang Shi" <yang.s@alibaba-inc.com> To: Michal Hocko <mhocko@kernel.org>, mingo@redhat.com Cc: akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm: use in_atomic() in print_vma_addr() Date: Fri, 03 Nov 2017 01:44:44 +0800 [thread overview] Message-ID: <ace5b078-652b-cbc0-176a-25f69612f7fa@alibaba-inc.com> (raw) In-Reply-To: <20171102075744.whhxjmqbdkfaxghd@dhcp22.suse.cz> On 11/2/17 12:57 AM, Michal Hocko wrote: > On Thu 02-11-17 05:38:33, Yang Shi wrote: >> commit 3e51f3c4004c9b01f66da03214a3e206f5ed627b >> ("sched/preempt: Remove PREEMPT_ACTIVE unmasking off in_atomic()") makes >> in_atomic() just check the preempt count, so it is not necessary to use >> preempt_count() in print_vma_addr() any more. Replace preempt_count() to >> in_atomic() which is a generic API for checking atomic context. > > But why? Is there some general work to get rid of the direct preempt_count > usage outside of the generic API? I may not articulate it in the commit log, I would say "in_atomic" is *preferred* API for checking atomic context instead of preempt_count() which should be used for retrieving the preemption count value. I would say there is not such general elimination work undergoing right now, but if we go through the kernel code, almost everywhere "in_atomic" is used for such use case already, except two places: - print_vma_addr() - debug_smp_processor_id() Both came from Ingo long time ago before commit 3e51f3c4004c9b01f66da03214a3e206f5ed627b ("sched/preempt: Remove PREEMPT_ACTIVE unmasking off in_atomic()"). But, after this commit was merged, I don't see why *not* use in_atomic() to follow the convention. Thanks, Yang > >> Signed-off-by: Yang Shi <yang.s@alibaba-inc.com> >> --- >> mm/memory.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/mm/memory.c b/mm/memory.c >> index a728bed..19b684e 100644 >> --- a/mm/memory.c >> +++ b/mm/memory.c >> @@ -4460,7 +4460,7 @@ void print_vma_addr(char *prefix, unsigned long ip) >> * Do not print if we are in atomic >> * contexts (in exception stacks, etc.): >> */ >> - if (preempt_count()) >> + if (in_atomic()) >> return; >> >> down_read(&mm->mmap_sem); >> -- >> 1.8.3.1 >
WARNING: multiple messages have this Message-ID (diff)
From: "Yang Shi" <yang.s@alibaba-inc.com> To: Michal Hocko <mhocko@kernel.org>, mingo@redhat.com Cc: akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm: use in_atomic() in print_vma_addr() Date: Fri, 03 Nov 2017 01:44:44 +0800 [thread overview] Message-ID: <ace5b078-652b-cbc0-176a-25f69612f7fa@alibaba-inc.com> (raw) In-Reply-To: <20171102075744.whhxjmqbdkfaxghd@dhcp22.suse.cz> On 11/2/17 12:57 AM, Michal Hocko wrote: > On Thu 02-11-17 05:38:33, Yang Shi wrote: >> commit 3e51f3c4004c9b01f66da03214a3e206f5ed627b >> ("sched/preempt: Remove PREEMPT_ACTIVE unmasking off in_atomic()") makes >> in_atomic() just check the preempt count, so it is not necessary to use >> preempt_count() in print_vma_addr() any more. Replace preempt_count() to >> in_atomic() which is a generic API for checking atomic context. > > But why? Is there some general work to get rid of the direct preempt_count > usage outside of the generic API? I may not articulate it in the commit log, I would say "in_atomic" is *preferred* API for checking atomic context instead of preempt_count() which should be used for retrieving the preemption count value. I would say there is not such general elimination work undergoing right now, but if we go through the kernel code, almost everywhere "in_atomic" is used for such use case already, except two places: - print_vma_addr() - debug_smp_processor_id() Both came from Ingo long time ago before commit 3e51f3c4004c9b01f66da03214a3e206f5ed627b ("sched/preempt: Remove PREEMPT_ACTIVE unmasking off in_atomic()"). But, after this commit was merged, I don't see why *not* use in_atomic() to follow the convention. Thanks, Yang > >> Signed-off-by: Yang Shi <yang.s@alibaba-inc.com> >> --- >> mm/memory.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/mm/memory.c b/mm/memory.c >> index a728bed..19b684e 100644 >> --- a/mm/memory.c >> +++ b/mm/memory.c >> @@ -4460,7 +4460,7 @@ void print_vma_addr(char *prefix, unsigned long ip) >> * Do not print if we are in atomic >> * contexts (in exception stacks, etc.): >> */ >> - if (preempt_count()) >> + if (in_atomic()) >> return; >> >> down_read(&mm->mmap_sem); >> -- >> 1.8.3.1 > -- 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:[~2017-11-02 17:45 UTC|newest] Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-11-01 21:38 [PATCH] mm: use in_atomic() in print_vma_addr() Yang Shi 2017-11-01 21:38 ` Yang Shi 2017-11-02 7:57 ` Michal Hocko 2017-11-02 7:57 ` Michal Hocko 2017-11-02 17:44 ` Yang Shi [this message] 2017-11-02 17:44 ` Yang Shi 2017-11-03 8:29 ` Michal Hocko 2017-11-03 8:29 ` Michal Hocko 2017-11-03 18:02 ` Andrew Morton 2017-11-03 18:02 ` Andrew Morton 2017-11-03 18:16 ` Yang Shi 2017-11-03 18:16 ` Yang Shi 2017-11-03 20:09 ` Bart Van Assche 2017-11-03 20:09 ` Bart Van Assche 2017-11-05 8:19 ` Michal Hocko 2017-11-05 8:19 ` Michal Hocko 2017-11-06 10:05 ` Peter Zijlstra 2017-11-06 10:05 ` Peter Zijlstra 2017-11-06 10:43 ` Michal Hocko 2017-11-06 10:43 ` Michal Hocko 2017-11-06 10:56 ` Michal Hocko 2017-11-06 10:56 ` Michal Hocko 2017-11-06 12:00 ` Peter Zijlstra 2017-11-06 12:00 ` Peter Zijlstra 2017-11-06 12:12 ` Michal Hocko 2017-11-06 12:12 ` Michal Hocko 2017-11-06 13:40 ` [PATCH] mm: do not rely on preempt_count in print_vma_addr (was: Re: [PATCH] mm: use in_atomic() in print_vma_addr()) Michal Hocko 2017-11-06 13:40 ` Michal Hocko 2017-11-06 14:19 ` [PATCH] mm: do not rely on preempt_count in print_vma_addr Vlastimil Babka 2017-11-06 14:19 ` Vlastimil Babka 2017-11-06 14:28 ` Michal Hocko 2017-11-06 14:28 ` Michal Hocko 2017-11-06 16:16 ` Yang Shi 2017-11-06 16:16 ` Yang Shi 2017-11-06 16:24 ` Michal Hocko 2017-11-06 16:24 ` Michal Hocko
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=ace5b078-652b-cbc0-176a-25f69612f7fa@alibaba-inc.com \ --to=yang.s@alibaba-inc.com \ --cc=akpm@linux-foundation.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mhocko@kernel.org \ --cc=mingo@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.