[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFzgno-7AcHxKMWGYrr2QAwEzXOieSghnsEfPQJ5aed-yQ@mail.gmail.com>
Date: Fri, 23 Mar 2012 12:39:59 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: paulmck@...ux.vnet.ibm.com
Cc: Ingo Molnar <mingo@...nel.org>, linux-kernel@...r.kernel.org,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Thomas Gleixner <tglx@...utronix.de>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [GIT PULL] RCU changes for v3.4
On Fri, Mar 23, 2012 at 12:21 PM, Paul E. McKenney
<paulmck@...ux.vnet.ibm.com> wrote:
>>
>> Please? Every time I look at some profiles, that silly rcu_read_lock
>> is there in the profile. It's annoying. I'd rather see it in the
>> function that invokes it.
>
> Let me see what I can do...
Thanks. To some degree, rcu_read_lock() is the more critical one,
because it is often in the much more critical path in the caller. In
particular, it's often at the beginning of a function, where a number
of arguments are "live", and calling it out-of-line also forces the
compiler to then save/restore those arguments (because they are
clobbered by the function call).
rcu_read_unlock() is *usually* not as critical, and is obviously much
harder to inline anyway due to the whole complexity with needing to
check if an RCU sequence has ended. It often is at the end of the
function call in the caller, when the only thing like is often just
the single return value (if that). So it seldom looks nearly as bad in
any profiles, because it doesn't tend to have the same kind of bad
impact on the call site.
Linus
--
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