linux-kernel - Re: [PATCH 1/5] Add a global synchronization point for pvclock

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]

Date:	Mon, 19 Apr 2010 11:32:19 -0300
From:	Glauber Costa <glommer@...hat.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Avi Kivity <avi@...hat.com>, kvm@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Jeremy Fitzhardinge <jeremy@...p.org>,
	Marcelo Tosatti <mtosatti@...hat.com>,
	Zachary Amsden <zamsden@...hat.com>
Subject: Re: [PATCH 1/5] Add a global synchronization point for pvclock

On Mon, Apr 19, 2010 at 01:19:43PM +0200, Peter Zijlstra wrote:
> On Mon, 2010-04-19 at 14:13 +0300, Avi Kivity wrote:
> > On 04/19/2010 01:56 PM, Peter Zijlstra wrote:
> > >
> > >    
> > >>> Right, do bear in mind that the x86 implementation of atomic64_read() is
> > >>> terrifyingly expensive, it is better to not do that read and simply use
> > >>> the result of the cmpxchg.
> > >>>
> > >>>
> > >>>        
> > >> atomic64_read() _is_ cmpxchg64b.  Are you thinking of some clever
> > >> implementation for smp i386?
> > >>      
> > >
> > > No, what I was suggesting was to rewrite that loop no to need the
> > > initial read but use the cmpxchg result of the previous iteration.
> > >
> > > Something like:
> > >
> > >    u64 last = 0;
> > >
> > >    /* more stuff */
> > >
> > >    do {
> > >      if (ret<  last)
> > >        return last;
> > >      last = cmpxchg64(&last_value, last, ret);
> > >    } while (last != ret);
> > >
> > > That only has a single cmpxchg8 in there per loop instead of two
> > > (avoiding the atomic64_read() one).
> > >    
> > 
> > Still have two cmpxchgs in the common case.  The first iteration will 
> > fail, fetching last_value, the second will work.
> > 
> > It will be better when we have contention, though, so it's worthwhile.
> 
> Right, another option is to put the initial read outside of the loop,
> that way you'll have the best of all cases, a single LOCK'ed op in the
> loop, and only a single LOCK'ed op for the fast path on sensible
> architectures ;-)
> 
>     last = atomic64_read(&last_value);
isn't a barrier enough here?


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