|| ||Rusty Russell <rusty-AT-au1.ibm.com>|
|| ||Re: [patch] RCU for low latency [2/2]|
|| ||Tue, 20 Jan 2004 10:25:04 +1100|
|| ||paul.mckenney-AT-us.ibm.com, linux-kernel-AT-vger.kernel.org|
In message <20040115060320.GA3985@in.ibm.com> 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 <email@example.com> 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 firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
to post comments)