On Fri, Dec 09, 2005 at 10:17:38PM +0300, Oleg Nesterov wrote:
> Srivatsa Vaddagiri wrote:
> >
> > On Thu, Dec 08, 2005 at 10:31:06PM +0300, Oleg Nesterov wrote:
> > > I can't see how this change can prevent idle cpus to be included in
> > > ->cpumask, cpu can add itself to nohz_cpu_mask right after some other
> > > cpu started new grace period.
> >
> > Yes that can happen, but if they check for rcu_pending right after that
> > it will prevent them from going tickless atleast (which will prevent grace
> > periods from being unnecessarily extended). Something like below:
> >
> > CPU0 CPU1
> >
> > rcp->cur++; /* New GP */
> >
> > smp_mb();
>
> I think I need some education on memory barriers.
>
> Does this mb() garantees that the new value of ->cur will be visible
> on other cpus immediately after smp_mb() (so that rcu_pending() will
> notice it) ?
AFAIK the new value of ->cur should be visible to other CPUs when smp_mb()
returns. Here's a definition of smp_mb() from Paul's article:
smp_mb(): "memory barrier" that orders both loads and stores. This means loads
and stores preceding the memory barrier are committed to memory before any
loads and stores following the memory barrier.
[ http://www.linuxjournal.com/article/8211 ]
> My understanding is that it only garantees that all stores before it
> must be visible before any store after mb. (yes, mb implies rmb, but
> I think it does not matter if CPU1 adds itself to nonhz mask after
> CPU0 reads nohz_cpu_mask). This means that CPU1 can read the stale
> value of ->cur. I guess I am wrong, but I can't prove it to myself.
>
> Could you please clarify this?
>
> Even simpler question:
>
> CPU0
> var = 1;
> wmb();
>
> after that CPU1 does rmb().
>
> Does it garantees that CPU1 will see the new value of var?
Again, going by the above article, I would expect CPU1 to see the new value of
var.
--
Thanks and Regards,
Srivatsa Vaddagiri,
Linux Technology Center,
IBM Software Labs,
Bangalore, INDIA - 560017
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
