lkml.org 
[lkml]   [2006]   [Apr]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch] RCU: introduce rcu_soon_pending() interface
    On Tue, Apr 25, 2006 at 07:27:21AM +0200, Heiko Carstens wrote:
    > > > @@ -485,6 +485,14 @@ int rcu_pending(int cpu)
    > > > __rcu_pending(&rcu_bh_ctrlblk, &per_cpu(rcu_bh_data, cpu));
    > > > }
    > > >
    > > > +int rcu_soon_pending(int cpu)
    > > > +{
    > > > + struct rcu_data *rdp = &per_cpu(rcu_data, cpu);
    > > > + struct rcu_data *rdp_bh = &per_cpu(rcu_bh_data, cpu);
    > > > +
    > > > + return (!!rdp->curlist || !!rdp_bh->curlist);
    > > > +}
    > >
    > > This patch sets my nerves a-jangling.
    > >
    > > What are the units of soonness? It's awfully waffly. Can we specify this
    > > more tightly?
    > >
    > > Neither rcu_pending() nor rcu_soon_pending() are commented or documented.
    > > Pity the poor user trying to work out what they do, and how they differ.
    > > They're global symbols and they form part of the RCU API - they should be
    > > kernel docified, please.
    > >
    > > There's probably a reason why neither of these symbols are exported to
    > > modules. Once they're actually documented I mught be able to work out what
    > > that reason is ;)
    >
    > Maybe rcu_batch_pending() would be a better name for rcu_soon_pending(). Also
    > rcu_batch_in_work() would be a more descriptive name for rcu_pending() as far
    > as I can tell.
    > Actually I was hoping for a better solution from the rcu experts, since I
    > don't like this too, but couldn't find something better.

    OK, got a look at your patch.

    You are using this internally, as part of the RCU -implementation-.
    You are determining whether this CPU will still be needed by RCU,
    or whether it can be turned off. So how 'bout calling the (internal)
    API something like rcu_needs_cpu()?

    int rcu_needs_cpu(int cpu)
    {
    struct rcu_data *rdp = &per_cpu(rcu_data, cpu);
    struct rcu_data *rdp_bh = &per_cpu(rcu_bh_data, cpu);

    return (!!rdp->curlist || !!rdp_bh->curlist || rcu_pending(cpu));
    }

    Then you can drop the rcu_pending() check from your 390 patch.

    Seem reasonable?

    The meaning of rcu_pending() is "Does RCU have some work pending on
    this CPU, so that there is a need to invoke rcu_check_callbacks() on
    this CPU?"

    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-04-25 13:49    [W:0.032 / U:0.004 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site