Re: [patch] RCU for low latency [2/2]

[Rusty Russell <rusty@au1.ibm.com>]

On Wed, 14 Jan 2004 13:54:20 +0530
Dipankar Sarma <dipankar@in.ibm.com> wrote:
> > static inline unsigned int max_rcu_at_once(int cpu)
> > {
> > 	if (in_softirq() && RCU_krcud(cpu) && rq_has_rt_task(cpu))
> > 		return rcu_max_bh_callbacks;
> > 	return (unsigned int)-1;
> > }
> 
> 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.

> > Ideally you'd create a new workqueue for this, or at the very least
> > use kthread primitives (once they're in -mm, hopefully soon).
> 
> I will use kthread primitives once they are available in mainline.

But ulterior motive is to push the kthread primitives by making as much
code depend on it as possible 8)

> I will clean this up later should we come to a conclusion that
> we need the low-latency changes in mainline. I don't see
> any non-driver kernel code using module_param() though.

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).

>From now on, I'm being more vigilant 8)

> New patch below. Needs rq-has-rt-task.patch I mailed earlier.
> There are more issues that need investigations - can we starve
> RCU callbacks leading to OOMs

You can screw your machine up with RT tasks, yes.  This is no new problem,
I think.

> should we compile out krcuds
> based on a config option (CONFIG_PREEMPT?). Any suggestions ?

Depends on the neatness of the code, I think...

Cheers,
Rusty.
-- 
   there are those who do and those who hang on and you don't see too
   many doers quoting their contemporaries.  -- Larry McVoy