From: Minchan Kim <minchan.kim@gmail.com>
To: Rakib Mullick <rakib.mullick@gmail.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
akpm@linux-foundation.org, Christoph Lameter <cl@linux.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Mel Gorman <mel@csn.ul.ie>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Subject: Re: [PATCH] mm, vmstat: Use cond_resched only when !CONFIG_PREEMPT
Date: Tue, 31 May 2011 14:57:57 +0900 [thread overview]
Message-ID: <20110531055756.GA2829@barrios-laptop> (raw)
In-Reply-To: <20110531055528.GB1519@barrios-laptop>
On Tue, May 31, 2011 at 02:55:28PM +0900, Minchan Kim wrote:
> On Mon, May 30, 2011 at 10:59:04PM +0600, Rakib Mullick wrote:
> > commit 468fd62ed9 (vmstats: add cond_resched() to refresh_cpu_vm_stats()) added cond_resched() in refresh_cpu_vm_stats. Purpose of that patch was to allow other threads to run in non-preemptive case. This patch, makes sure that cond_resched() gets called when !CONFIG_PREEMPT is set. In a preemptiable kernel we don't need to call cond_resched().
> >
> > Signed-off-by: Rakib Mullick <rakib.mullick@gmail.com>
>
> Let me ask questions.
>
> 1. What's bad if we call cond_resched on CONFIG_PREEMPT?
> Is refresh_cpu_vm_stats a hot path?
> 2. There is no help to call explicit scheduling point on CONFIG_PREEMPTION?
>
> We used cond_resched without any ifdef/endif of CONFIG_PREEMPT.
> In addtion, cond_resched includes __might_sleep which is debugging help for lock.
> So I hope let it be if you have a big concern.
typo ^^
unless
--
Kind regards
Minchan Kim
WARNING: multiple messages have this Message-ID (diff)
From: Minchan Kim <minchan.kim@gmail.com>
To: Rakib Mullick <rakib.mullick@gmail.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
akpm@linux-foundation.org, Christoph Lameter <cl@linux.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Mel Gorman <mel@csn.ul.ie>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Subject: Re: [PATCH] mm, vmstat: Use cond_resched only when !CONFIG_PREEMPT
Date: Tue, 31 May 2011 14:57:57 +0900 [thread overview]
Message-ID: <20110531055756.GA2829@barrios-laptop> (raw)
In-Reply-To: <20110531055528.GB1519@barrios-laptop>
On Tue, May 31, 2011 at 02:55:28PM +0900, Minchan Kim wrote:
> On Mon, May 30, 2011 at 10:59:04PM +0600, Rakib Mullick wrote:
> > commit 468fd62ed9 (vmstats: add cond_resched() to refresh_cpu_vm_stats()) added cond_resched() in refresh_cpu_vm_stats. Purpose of that patch was to allow other threads to run in non-preemptive case. This patch, makes sure that cond_resched() gets called when !CONFIG_PREEMPT is set. In a preemptiable kernel we don't need to call cond_resched().
> >
> > Signed-off-by: Rakib Mullick <rakib.mullick@gmail.com>
>
> Let me ask questions.
>
> 1. What's bad if we call cond_resched on CONFIG_PREEMPT?
> Is refresh_cpu_vm_stats a hot path?
> 2. There is no help to call explicit scheduling point on CONFIG_PREEMPTION?
>
> We used cond_resched without any ifdef/endif of CONFIG_PREEMPT.
> In addtion, cond_resched includes __might_sleep which is debugging help for lock.
> So I hope let it be if you have a big concern.
typo ^^
unless
--
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 internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2011-05-31 5:58 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-30 16:59 [PATCH] mm, vmstat: Use cond_resched only when !CONFIG_PREEMPT Rakib Mullick
2011-05-30 16:59 ` Rakib Mullick
2011-05-30 23:38 ` KAMEZAWA Hiroyuki
2011-05-30 23:38 ` KAMEZAWA Hiroyuki
2011-05-31 3:13 ` Rakib Mullick
2011-05-31 3:13 ` Rakib Mullick
2011-05-31 3:18 ` KAMEZAWA Hiroyuki
2011-05-31 3:18 ` KAMEZAWA Hiroyuki
2011-05-31 3:58 ` Rakib Mullick
2011-05-31 3:58 ` Rakib Mullick
2011-05-31 4:29 ` KAMEZAWA Hiroyuki
2011-05-31 4:29 ` KAMEZAWA Hiroyuki
2011-05-31 2:23 ` KOSAKI Motohiro
2011-05-31 2:23 ` KOSAKI Motohiro
2011-05-31 3:19 ` Rakib Mullick
2011-05-31 3:19 ` Rakib Mullick
2011-05-31 5:55 ` Minchan Kim
2011-05-31 5:55 ` Minchan Kim
2011-05-31 5:57 ` Minchan Kim [this message]
2011-05-31 5:57 ` Minchan Kim
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=20110531055756.GA2829@barrios-laptop \
--to=minchan.kim@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mel@csn.ul.ie \
--cc=rakib.mullick@gmail.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: 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.