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] [day] [month] [year] [list]
Message-ID: <20071128155131.GA4376@linux.vnet.ibm.com>
Date:	Wed, 28 Nov 2007 07:51:31 -0800
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	James Huang <James.Huang@...chguard.com>
Cc:	linux-kernel@...r.kernel.org,
	Manfred Spraul <manfred@...orfullife.com>,
	jamesclhuang@...oo.com, ego@...ibm.com, akpm@...ux-foundation.org
Subject: Re: __rcu_process_callbacks() in Linux 2.6

On Tue, Nov 27, 2007 at 10:21:08PM -0800, Paul E. McKenney wrote:
> On Tue, Nov 27, 2007 at 05:49:15PM -0800, Paul E. McKenney wrote:
> > On Mon, Nov 26, 2007 at 06:39:58PM -0800, Paul E. McKenney wrote:
> > > On Mon, Nov 26, 2007 at 02:48:08PM -0800, James Huang wrote:

[ . . . ]

> > > That is correct.  This does mean that we should be able to leverage
> > > locking primitives and memory barriers executed from the scheduling
> > > clock interrupt.
> > 
> > And I managed to get some time on a 64-CPU POWER5+ system.  Been running
> > rcutorture for about 2.5 hours without a failure (128 reader processes)
> > running through not quite 1.5M RCU updates.  Of course, this is not
> > proof that the Classic RCU implementation works, but is should provide
> > some reassurance.
> > 
> > I will keep it running until I get kicked off (probably rather soon).
> 
> More than seven hours, more than 4M RCU updates without failure.
> Someone else's turn for the machine.
> 
> Again, not proof, but at least some reassurance.

Just to avoid potential misunderstanding...  This testing in no way
changes my opinion that the RCU Classic implementation needs some
combination of documentation and rework.  It pretty clearly needs a
bit of both.  And the increase in core counts over the past few years
indicates that some scalability work is in order.

What this testing does demonstrate is that we are not in an emergency
situation.

						Thanx, Paul
-
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