[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090325165713.GA14250@elte.hu>
Date: Wed, 25 Mar 2009 17:57:13 +0100
From: Ingo Molnar <mingo@...e.hu>
To: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc: linux-tip-commits@...r.kernel.org, linux-kernel@...r.kernel.org,
hpa@...or.com, mingo@...hat.com, penberg@...helsinki.fi,
eduard.munteanu@...ux360.ro, tglx@...utronix.de
Subject: Re: [tip:tracing/kmemtrace] rcutree: fix rcu_tree_trace.c data
structure dependencies
* Paul E. McKenney <paulmck@...ux.vnet.ibm.com> wrote:
> > I think many of the data definitions (and the resulting include
> > file dependencies) in include/linux/rcu*.h could move into
> > kernel/rcu*.h and be privatized that way. 'struct rcu_state'
> > would be an example.
> >
> > Agreed?
>
> In principle, yes. In practice, my attempts to make headway in
> this direction have usually collided with the desire to inline
> some of the functions that appear on fastpaths, so I would prefer
> caution when moving in this direction, especially given my
> treercu-related todos, to which "speeding up synchronize_rcu()"
> just got added.
I think there's a solution, for example the quiescent-state inlines
could still be offered in a kernel/rcupdate_internals.h header to be
included by kernel/softirq.c et al directly.
Otherwise ... i think it generally is not worth the trouble to put
huge data types into common headers just to be able to inline into a
small number of callsites.
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists