From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Josh Triplett <josh@joshtriplett.org>,
Lai Jiangshan <laijs@cn.fujitsu.com>,
Peter Zijlstra <peterz@infradead.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/1] rcu: uninline rcu_read_lock_held()
Date: Tue, 8 Jul 2014 15:20:35 -0700 [thread overview]
Message-ID: <20140708222035.GD4603@linux.vnet.ibm.com> (raw)
In-Reply-To: <20140702185935.GB18357@redhat.com>
On Wed, Jul 02, 2014 at 08:59:35PM +0200, Oleg Nesterov wrote:
> Uninline rcu_read_lock_held(). According to size vmlinux this saves
> 28549 in .text:
>
> - 5541731 3014560 14757888 23314179
> + 5513182 3026848 14757888 23297918
>
> Note: it looks as if the data grows by 12288 bytes but this is not true,
> it does not actually grow. But .data starts with ALIGN(THREAD_SIZE) and
> since .text shrinks the padding grows, and thus .data grows too as it
> seen by /bin/size. diff System.map:
>
> - ffffffff81510000 D _sdata
> - ffffffff81510000 D init_thread_union
> + ffffffff81509000 D _sdata
> + ffffffff8150c000 D init_thread_union
>
> Perhaps we can change vmlinux.lds.S to .data itself, so that /bin/size
> can't "wrongly" report that .data grows if .text shinks.
>
> Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Queued for 3.18, thank you, Oleg!
I removed the "extern" tags, apparently people don't like them on
function declarations anymore.
Thanx, Paul
> ---
> include/linux/rcupdate.h | 38 ++------------------------------------
> kernel/rcu/update.c | 32 ++++++++++++++++++++++++++++++++
> 2 files changed, 34 insertions(+), 36 deletions(-)
>
> diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> index e8c55d8..8980817 100644
> --- a/include/linux/rcupdate.h
> +++ b/include/linux/rcupdate.h
> @@ -378,42 +378,8 @@ extern void rcu_lock_release_bh(void);
> extern void rcu_lock_acquire_sched(void);
> extern void rcu_lock_release_sched(void);
>
> -/**
> - * rcu_read_lock_held() - might we be in RCU read-side critical section?
> - *
> - * If CONFIG_DEBUG_LOCK_ALLOC is selected, returns nonzero iff in an RCU
> - * read-side critical section. In absence of CONFIG_DEBUG_LOCK_ALLOC,
> - * this assumes we are in an RCU read-side critical section unless it can
> - * prove otherwise. This is useful for debug checks in functions that
> - * require that they be called within an RCU read-side critical section.
> - *
> - * Checks debug_lockdep_rcu_enabled() to prevent false positives during boot
> - * and while lockdep is disabled.
> - *
> - * Note that rcu_read_lock() and the matching rcu_read_unlock() must
> - * occur in the same context, for example, it is illegal to invoke
> - * rcu_read_unlock() in process context if the matching rcu_read_lock()
> - * was invoked from within an irq handler.
> - *
> - * Note that rcu_read_lock() is disallowed if the CPU is either idle or
> - * offline from an RCU perspective, so check for those as well.
> - */
> -static inline int rcu_read_lock_held(void)
> -{
> - if (!debug_lockdep_rcu_enabled())
> - return 1;
> - if (!rcu_is_watching())
> - return 0;
> - if (!rcu_lockdep_current_cpu_online())
> - return 0;
> - return lock_is_held(&rcu_lock_map);
> -}
> -
> -/*
> - * rcu_read_lock_bh_held() is defined out of line to avoid #include-file
> - * hell.
> - */
> -int rcu_read_lock_bh_held(void);
> +extern int rcu_read_lock_held(void);
> +extern int rcu_read_lock_bh_held(void);
>
> /**
> * rcu_read_lock_sched_held() - might we be in RCU-sched read-side critical section?
> diff --git a/kernel/rcu/update.c b/kernel/rcu/update.c
> index c2209eb..ea4af81 100644
> --- a/kernel/rcu/update.c
> +++ b/kernel/rcu/update.c
> @@ -137,6 +137,38 @@ int notrace debug_lockdep_rcu_enabled(void)
> EXPORT_SYMBOL_GPL(debug_lockdep_rcu_enabled);
>
> /**
> + * rcu_read_lock_held() - might we be in RCU read-side critical section?
> + *
> + * If CONFIG_DEBUG_LOCK_ALLOC is selected, returns nonzero iff in an RCU
> + * read-side critical section. In absence of CONFIG_DEBUG_LOCK_ALLOC,
> + * this assumes we are in an RCU read-side critical section unless it can
> + * prove otherwise. This is useful for debug checks in functions that
> + * require that they be called within an RCU read-side critical section.
> + *
> + * Checks debug_lockdep_rcu_enabled() to prevent false positives during boot
> + * and while lockdep is disabled.
> + *
> + * Note that rcu_read_lock() and the matching rcu_read_unlock() must
> + * occur in the same context, for example, it is illegal to invoke
> + * rcu_read_unlock() in process context if the matching rcu_read_lock()
> + * was invoked from within an irq handler.
> + *
> + * Note that rcu_read_lock() is disallowed if the CPU is either idle or
> + * offline from an RCU perspective, so check for those as well.
> + */
> +int rcu_read_lock_held(void)
> +{
> + if (!debug_lockdep_rcu_enabled())
> + return 1;
> + if (!rcu_is_watching())
> + return 0;
> + if (!rcu_lockdep_current_cpu_online())
> + return 0;
> + return lock_is_held(&rcu_lock_map);
> +}
> +EXPORT_SYMBOL_GPL(rcu_read_lock_held);
> +
> +/**
> * rcu_read_lock_bh_held() - might we be in RCU-bh read-side critical section?
> *
> * Check for bottom half being disabled, which covers both the
> --
> 1.5.5.1
>
>
prev parent reply other threads:[~2014-07-08 22:20 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-30 16:18 [PATCH v4 0/2] rcu: uninline rcu_lock_acquire() and rcu_lock_release() Oleg Nesterov
2014-06-30 16:18 ` [PATCH v4 1/2] " Oleg Nesterov
2014-07-01 11:41 ` Peter Zijlstra
2014-07-01 16:40 ` Oleg Nesterov
2014-07-08 22:22 ` Paul E. McKenney
2014-06-30 16:18 ` [PATCH v4 2/2] rcu: change rcu_dereference_check(c) to check "c" first Oleg Nesterov
2014-06-30 20:24 ` [PATCH v4 0/2] rcu: uninline rcu_lock_acquire() and rcu_lock_release() Paul E. McKenney
2014-07-01 14:55 ` Oleg Nesterov
2014-07-02 15:39 ` Oleg Nesterov
2014-07-02 18:59 ` [PATCH 0/1] rcu: uninline rcu_read_lock_held() Oleg Nesterov
2014-07-02 18:59 ` [PATCH 1/1] " Oleg Nesterov
2014-07-08 22:20 ` Paul E. McKenney [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140708222035.GD4603@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=josh@joshtriplett.org \
--cc=laijs@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=peterz@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox