lkml.org 
[lkml]   [2006]   [Jun]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 1/2] srcu: RCU variant permitting read-side blocking
    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" <paulmck@us.ibm.com> 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 majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-06-27 03:39    [W:2.450 / U:0.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site