Date: Thu, 15 Jan 2004 10:35:00 +1100
From: Rusty Russell <rusty@au1.ibm.com>
To: dipankar@in.ibm.com
Cc: rusty@au1.ibm.com, paul.mckenney@us.ibm.com, linux-kernel@vger.kernel.org
Subject: Re: [patch] RCU for low latency [2/2]
Message-Id: <20040115103500.28f9e1bf.rusty@rustcorp.com.au>
In-Reply-To: <20040114082420.GA3755@in.ibm.com>
References: <20040108115051.GC5128@in.ibm.com>
	<20040109000244.8C58D17DDE@ozlabs.au.ibm.com>
	<20040114082420.GA3755@in.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1983
Lines: 54

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
-
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/