Messages in this thread | | | From | Rusty Russell <> | Subject | Re: [patch] RCU for low latency [2/2] | Date | Tue, 20 Jan 2004 10:25:04 +1100 |
| |
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 <dipankar@in.ibm.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 Speedos.
> > 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) Rusty. -- 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 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/
| |