netdev - Re: [PATCHv5 2/2] memory barrier: adding smp_mb__after

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: <20090703154007.GC10256@Krystal>
Date:	Fri, 3 Jul 2009 11:40:07 -0400
From:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
To:	Herbert Xu <herbert@...dor.apana.org.au>
Cc:	mingo@...e.hu, jolsa@...hat.com, a.p.zijlstra@...llo.nl,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	fbl@...hat.com, nhorman@...hat.com, davem@...hat.com,
	htejun@...il.com, jarkao2@...il.com, oleg@...hat.com,
	davidel@...ilserver.org, eric.dumazet@...il.com,
	Paul.McKenney@...ibm.com
Subject: Re: [PATCHv5 2/2] memory barrier: adding smp_mb__after_lock

* Herbert Xu (herbert@...dor.apana.org.au) wrote:
> Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca> wrote:
> > 
> > Why don't we create a read_lock without acquire semantic instead (e.g.
> > read_lock_nomb(), or something with a better name like __read_lock()) ?
> > On architectures where memory barriers are needed to provide the acquire
> > semantic, it would be faster to do :
> > 
> > __read_lock();
> > smp_mb();
> > 
> > than :
> > 
> > read_lock(); <- e.g. lwsync + isync or something like that
> > smp_mb(); <- full sync.
> 
> Hmm, why do we even care when read_lock should just die?
> 

I guess you are proposing migration from rwlock to RCU ?

Well, in cases where critical sections are in the order of 20000
cycles or more, and with 8 to 64-core machines, there is no significant
gain in using RCU vs rwlocks, so the added complexity might not be
justified if the critical sections are very long.

But then it's a case by case thing. We would have to see what exactly is
protected by this read lock and how long the critical section is.
However, in any case, you are right: rwlocks are acceptable only for
long critical sections, for which we just don't care about one extra
memory barrier.

Instead of optimizing away these read-side rwlock barriers, we would
spend our time much more efficiently switching to RCU read side.

Mathieu

> Cheers,
> -- 
> Visit Openswan at http://www.openswan.org/
> Email: Herbert Xu ~{PmV>HI~} <herbert@...dor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html