Re: Real-Time Preemption and RCU

From: Ingo Molnar <mingo@elte.hu>
To: "Paul E. McKenney" <paulmck@us.ibm.com>
Cc: dipankar@in.ibm.com, shemminger@osdl.org, akpm@osdl.org,
	torvalds@osdl.org, rusty@au1.ibm.com, tgall@us.ibm.com,
	jim.houston@comcast.net, manfred@colorfullife.com, gh@us.ibm.com,
	linux-kernel@vger.kernel.org
Subject: Re: Real-Time Preemption and RCU
Date: Fri, 18 Mar 2005 12:38:11 +0100	[thread overview]
Message-ID: <20050318113811.GA18997@elte.hu> (raw)
In-Reply-To: <20050318002026.GA2693@us.ibm.com>

* Paul E. McKenney <paulmck@us.ibm.com> wrote:

> 5. Scalability -and- Realtime Response.
> 
> The trick here is to keep track of the CPU that did the
> rcu_read_lock() in the task structure.  If there is a preemption,
> there will be some slight inefficiency, but the correct lock will be
> released, preserving correctness.

the inefficiency will be larger, because (as explained in a previous
mail) multiple concurrent owners of the read-lock are not allowed. This
adds to the overhead of PREEMPT_RT on SMP, but is an intentional
tradeoff. I dont expect PREEMPT_RT to be used on an Altix :-|

#5 is still the best option, because in the normal 'infrequent
preemption' case it will behave in a cache-friendly way. A positive
effect of the lock serializing is that the callback backlog will stay
relatively small and that the RCU backlog processing can be made
deterministic as well (if needed), by making the backlog processing
thread(s) SCHED_FIFO.

	Ingo