lkml.org 
[lkml]   [2009]   [Mar]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [tip:tracing/kmemtrace] rcutree: fix rcu_tree_trace.c data structure dependencies
    On Wed, Mar 25, 2009 at 05:57:13PM +0100, Ingo Molnar wrote:
    >
    > * Paul E. McKenney <paulmck@linux.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.

    Could definitely do this, as I used to do it this way in a former life.
    As long as we are now OK with creating an additional header file or two
    per flavor of RCU.

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

    Information hiding can indeed be a good thing.

    Thanx, Paul


    \
     
     \ /
      Last update: 2009-03-26 04:37    [W:0.024 / U:1.736 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site