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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.1.10.0905081012420.23875@qirst.com>
Date:	Fri, 8 May 2009 10:16:10 -0400 (EDT)
From:	Christoph Lameter <cl@...ux.com>
To:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
cc:	Peter Zijlstra <peterz@...radead.org>,
	Alok Kataria <akataria@...are.com>,
	"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	the arch/x86 maintainers <x86@...nel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	"alan@...rguk.ukuu.org.uk" <alan@...rguk.ukuu.org.uk>
Subject: Re: [PATCH] x86: Reduce the default HZ value

On Fri, 8 May 2009, Paul E. McKenney wrote:

> > Can't you simply enter idle state after a grace period completes and
> > finds no pending callbacks for the next period. And leave idle state at
> > the next call_rcu()?
>
> If there were no RCU callbacks -globally- across all CPUs, yes.  But
> the check at the end of rcu_irq_exit() is testing only on the current
> CPU.  Checking across all CPUs is expensive and racy.
>
> So what happens instead is that there is rcu_needs_cpu(), which gates
> entry into dynticks-idle mode.  This function returns 1 if there are
> callbacks on the current CPU.  So, if no CPU has an RCU callback, then
> all CPUs can enter dynticks-idle mode so that the entire system is
> quiescent from an RCU viewpoint -- no RCU processing at all.

Did not follow RCU developments. But wasnt there a time when RCU periods
were processor specific and a global RCU period was done when all the
processors went through their rcu periods?

Cpu cache hotness may not be relevant to RCU since rcu involves long time
periods in which cachelines cool down. Can the RCU callbacks all be done
on processor 0 (or a so designated processor)? That would avoiding
disturbances of the other processors.



--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ