On Wed, 2016-07-06 at 17:10 +0100, George Dunlap wrote: > On Mon, Jun 20, 2016 at 8:56 AM, Jan Beulich <jbeul...@suse.com> > wrote: > > > > > > > On 18.06.16 at 01:12, <dario.faggi...@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)
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel