lkml.org 
[lkml]   [2005]   [Mar]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Real-Time Preemption and RCU
On Fri, Mar 18, 2005 at 06:11:26PM +0100, Ingo Molnar wrote:
>
> * Paul E. McKenney <paulmck@us.ibm.com> wrote:
>
> > For the patch, here are my questions:
> >
> > o What is the best way to select between classic RCU and this
> > scheme?
> >
> > 1. Massive #ifdef across rcupdate.c
> >
> > 2. Create an rcupdate_rt.c and browbeat the build system
> > into picking one or the other (no clue if this is
> > possible...)
> >
> > 3. Create an rcupdate_rt.c and rely on the linker to pick
> > one or the other, with rcupdate.h generating different
> > external symbol names to make the choice.
>
> you can also go for option #0: just replace the existing RCU code with
> the new one, and i'll then deal with the configuration details.

Having just spent the past few minutes descending into #ifdef hell,
I agree completely with your option #0.

> what will have to happen is most likely #2 (since there is near zero
> code sharing between the two variants, right?). Picking rcupdate_rt.c is
> as simple as doing this:
>
> obj-$(CONFIG_DONT_PREEMPT_RCU) += rcupdate.o
> obj-$(CONFIG_PREEMPT_RCU) += rcupdate_rt.o
>
> and then use Kconfig to generate either CONFIG_DONT_PREEMPT_RCU
> (default) or CONFIG_PREEMPT_RCU (if the user selects it).

Cool! Thank you for the tutorial! And yes, there is no shared code
that I can see.

> but it's not yet clear whether we want to offer this to users as a
> configurable option. The simplest solution for you would be to go with
> option #0 :-) [or if you prefer switchability, #1 is good too - i can
> then extract the bits and do #2 based on that.]

Option #0 it is -- I will stick with the locking algorithms and let
wiser and more experienced heads work out the configuration issues.

> > o How best to interface to OOM? Left to myself, I leave this
> > for later. ;-)
>
> yeah, i'd not worry about OOM that much at this stage.
>
> > I will take the cowardly approach of patching against the upstream
> > kernel.
>
> sure. This is in fact easier for me: i'll first rip all my RCU hackery
> out of -RT and then add your code, so the base i'll be merging against
> will be closer to upstream than to current -RT.

Sounds good to me!

Thanx, Paul
-
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/

\
 
 \ /
  Last update: 2005-03-22 14:11    [W:0.104 / U:0.908 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site