[lkml]   [2004]   [Jan]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch] RCU for low latency [2/2]
    In message <> you write:
    > On Thu, Jan 15, 2004 at 10:35:00AM +1100, Rusty Russell wrote:
    > > On Wed, 14 Jan 2004 13:54:20 +0530
    > > Dipankar Sarma <> wrote:
    > > > Done, except that once we reach the callback limit, we need to check
    > > > for RT tasks after every callback, instead of at the start of the RCU batch.
    > >
    > > AFAICT, if you're in a softirq it can't change. If you're not, there's
    > > no limit anyway.
    > What if a blocked RT task was woken up by an irq that interrupted
    > RCU callback processing ? All of a sudden you now have a RT task
    > in the queue. Isn't this possible ?

    Yes, you're absolutely right. You could just handle this by breaking
    out of the loop (after processing one rcu) as soon as there's a
    runnable rt task, independent of limit.

    > > But ulterior motive is to push the kthread primitives by making as much
    > > code depend on it as possible 8)
    > hehe. How nefarious :-)

    Well, you don't get to be a kernel hacker simply by looking good in

    > > I'm trying to catch them as new ones get introduced. If the name is
    > > old-style, then there's little point changing (at least for 2.6).
    > OK, but I am not sure how to do this for non-module code.

    module_param() works for non-module code (it automatically inserts a
    "rcu." prefix in the name though).

    > > You can screw your machine up with RT tasks, yes. This is no new problem,
    > > I think.
    > That is another way to look at it :)

    I think it's fair, though. If you really absorb all your CPU with RT
    tasks, you will starve important things: that's why RT is a root priv.

    > > > should we compile out krcuds
    > > > based on a config option (CONFIG_PREEMPT?). Any suggestions ?
    > >
    > > Depends on the neatness of the code, I think...
    > Well there seems to be a difference in opinion about whether the
    > krcuds should be pervasive or not. Some think they should be,
    > some thinks they should not be when we aren't aiming for low
    > latency (say CONFIG_PREEMPT=n).

    Personally I don't like overloading the semantic of CONFIG_PREEMPT.
    But I think CONFIG_PREEMPT is a bad idea anyway: it's not really a
    question you can ask a user during config.

    CONFIG_LOW_LATENCY (Description: Sacrifice some raw performance to
    increase latency) makes more sense, and would fit here, too.

    Another option is to overload ksoftirq to do what krcud does: they're
    v. similar in nature AFAICT.

    Sorry I can't be more helpful 8)
    Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:00    [W:0.022 / U:0.676 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site