On Wed, 2016-07-06 at 17:10 +0100, George Dunlap wrote:
> On Mon, Jun 20, 2016 at 8:56 AM, Jan Beulich <JBeulich@suse.com>
> wrote:
> > 
> > > > > On 18.06.16 at 01:12, <dario.faggioli@citrix.com> wrote:
> > > Yet another situation very similar to 779511f4bf5ae
> > > ("sched: avoid races on time values read from NOW()").
> > > 
> > > In fact, when more than one runqueue is involved, we need
> > > to make sure that the following does not happen:
> > >  1. take the lock of 1st runq
> > >  2. now = NOW()
> > >  3. take the lock of 2nd runq
> > >  4. use now
> > > 
> > > as, if we have to wait at step 3, the value in now may
> > > be stale when we get to use it at step 4.
> > Is this really meaningful here? We're talking of trylocks, which
> > don't
> > incur any delay other than the latency of the LOCKed (on x86)
> > instruction to determine lock availability.
> This makes sense to me -- Dario?
> 
Yes, I think this patch is, after all, not really necessary.

Thanks and Regards,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)