linux-kernel - Re: [PATCH] mm, vmstat: Use cond_resched only when !CONFIG

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20110531055528.GB1519@barrios-laptop>
Date:	Tue, 31 May 2011 14:55:28 +0900
From:	Minchan Kim <minchan.kim@...il.com>
To:	Rakib Mullick <rakib.mullick@...il.com>
Cc:	linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	akpm@...ux-foundation.org, Christoph Lameter <cl@...ux.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Mel Gorman <mel@....ul.ie>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
Subject: Re: [PATCH] mm, vmstat: Use cond_resched only when !CONFIG_PREEMPT

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@...il.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.

-- 
Kind regards
Meinchan Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/