On Mon, Jun 26, 2006 at 06:14:18PM -0700, Andrew Morton wrote:
> On Mon, 26 Jun 2006 17:53:51 -0700
> "Paul E. McKenney" <[email protected]> wrote:
>
> > > > +struct srcu_struct_array {
> > > > + int c[2];
> > > > +} ____cacheline_internode_aligned_in_smp;
> > >
> > > ____cacheline_internode_aligned_in_smp isn't implemented..
> >
> > It was not long ago... :-/
>
> I was trying to work out why on earth this compiled.
>
> It gives you a global variable called
> ____cacheline_internode_aligned_in_smp. That works nicely until you
> include this header file from two .c files, at which time you get two
> global variables called ____cacheline_internode_aligned_in_smp. And the
> linker will happily swallow even that unless you're using -fno-common.
Hmmm...
Sounds like percpu_alloc() is strongly recommended. Made the changes,
compiling, hope to test overnight.
> > > > + if (sum == 0)
> > > > + break;
> > > > + schedule_timeout_interruptible(1);
> > > > + }
> > >
> > > Little sleeps like this are a worry. It's usually an indication that we've
> > > been lazy and haven't put in the wakeups which are needed for a
> > > minimum-latency wait.
> >
> > I have been even -more- lazy and have absolutely -no- wakeups. ;-)
> > The alternative would be to have srcu_read_unlock() wake up the
> > task doing the synchronize_srcu(), but getting that right is painful.
>
> Shouldn't be too hard...
>
> A wakeup can be relatively expensive, but one can often do
>
> if (something_which_is_inexpensive())
> wake_up(...);
>
> although it takes care.
Exactly. ;-) Been there, done that, gotten it right, but have also
run up almost every blind alley that there is.
Besides, prior to this, there is a synchronize_sched(). In many cases,
the readers will have all completed during the synchronize_sched()
latency, so my bet is that the extra complexity will have no benefit in
the common case. And if someone comes up with with a good reason to do
a blocking network receive or some such in the SRCU read-side critical
sections, I will be happy to add the wakeup machinations.
Fair enough?
(Besides, we will want to save some of the complexity budget for a
hierarchical implementation should Jesse Barnes prove correct about
future 1,000-CPU dies, right?)
> if you want to be _really_ sleazy you can do
>
> if (something_which_is_inexpensive_and_isnt_quite_right())
> wake_up(...);
>
> and, at the other end:
>
> while (something) {
> schedule_timeout_interruptible(1);
> }
>
> and rely upon the flakey-wakeup to work most of the time, so it usually
> interrupts the sleep.
Urg...
> Now erase this from your mind.
To erase it from my mind, I would have had to allow it to get that far
in the first place. ;-)
Thanx, Paul
-
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]
