linux-kernel - False-positive RCU stall warnings on large systems...

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-next>] [day] [month] [year] [list]

Message-ID: <5123A984.4000704@numascale-asia.com>
Date:	Wed, 20 Feb 2013 00:34:12 +0800
From:	Daniel J Blueman <daniel@...ascale-asia.com>
To:	"Paul E. McKenney" <paul.mckenney@...aro.org>
CC:	Steffen Persvold <sp@...ascale.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: False-positive RCU stall warnings on large systems...

Hi Paul,

On some of our larger servers with many hundreds of cores and when under 
high duress, we can see scheduler RCU stall warnings [1], so find we 
have to increase the hardcoded RCU_STALL_RAT_DELAY up from 2 and 
RCU_JIFFIES_TILL_FORCE_QS up from 3.

Is there a more sustainable way to account for this to avoid it being 
hard-coded, such as making it and dependent timeouts a fraction of 
CONFIG_RCU_CPU_STALL_TIMEOUT?

On the other hand, perhaps this is just caused by clock jitter (eg due 
to distance from a contended clock source)? So increasing these a bit 
may just be adequate in general...

Many thanks,
   Daniel

--- [1]

[ 3939.010085] INFO: rcu_sched detected stalls on CPUs/tasks: {} 
(detected by 1, t=29662 jiffies, g=3053, c=3052, q=598)
[ 3939.020008] INFO: Stall ended before state dump start
-- 
Daniel J Blueman
Principal Software Engineer, Numascale Asia
--
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/