From: Jesper Dangaard Brouer <brouer@redhat.com>
To: Rao Shoaib <rao.shoaib@oracle.com>
Cc: linux-kernel@vger.kernel.org, paulmck@linux.vnet.ibm.com,
linux-mm@kvack.org, brouer@redhat.com
Subject: Re: [PATCH] kfree_rcu() should use the new kfree_bulk() interface for freeing rcu structures
Date: Wed, 20 Dec 2017 08:31:21 +0100 [thread overview]
Message-ID: <20171220083121.4aaa8a2a@redhat.com> (raw)
In-Reply-To: <75f514a6-8121-7d5f-4b6a-7e68d8f226a8@oracle.com>
On Tue, 19 Dec 2017 13:20:43 -0800 Rao Shoaib <rao.shoaib@oracle.com> wrote:
> On 12/19/2017 12:41 PM, Jesper Dangaard Brouer wrote:
> > On Tue, 19 Dec 2017 09:52:27 -0800 rao.shoaib@oracle.com wrote:
> >
> >> +/* Main RCU function that is called to free RCU structures */
> >> +static void
> >> +__rcu_bulk_free(struct rcu_head *head, rcu_callback_t func, int cpu, bool lazy)
> >> +{
> >> + unsigned long offset;
> >> + void *ptr;
> >> + struct rcu_bulk_free *rbf;
> >> + struct rcu_bulk_free_container *rbfc = NULL;
> >> +
> >> + rbf = this_cpu_ptr(&cpu_rbf);
> >> +
> >> + if (unlikely(!rbf->rbf_init)) {
> >> + spin_lock_init(&rbf->rbf_lock);
> >> + rbf->rbf_cpu = smp_processor_id();
> >> + rbf->rbf_init = true;
> >> + }
> >> +
> >> + /* hold lock to protect against other cpu's */
> >> + spin_lock_bh(&rbf->rbf_lock);
> >
> > I'm not sure this will be faster. Having to take a cross CPU lock here
> > (+ BH-disable) could cause scaling issues. Hopefully this lock will
> > not be used intensively by other CPUs, right?
> >
[...]
>
> As Paul has pointed out the lock is a per-cpu lock, the only reason for
> another CPU to access this lock is if the rcu callbacks run on a
> different CPU and there is nothing the code can do to avoid that but
> that should be rare anyways.
(loop in Paul's comment)
On Tue, 19 Dec 2017 12:56:29 -0800
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
> Isn't this lock in a per-CPU object? It -might- go cross-CPU in response
> to CPU-hotplug operations, but that should be rare.
Point taken. If this lock is very unlikely to be taken on another CPU
then I withdraw my performance concerns (the cacheline can hopefully
stay in Modified(M) state on this CPU, and all other CPUs will have in
in Invalid(I) state based on MESI cache coherence protocol view[1]).
The lock's atomic operation does have some overhead, and _later_ if we
could get fancy and use seqlock (include/linux/seqlock.h) to remove
that.
[1] https://en.wikipedia.org/wiki/MESI_protocol
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2017-12-20 7:31 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-19 17:52 rao.shoaib
2017-12-19 19:12 ` Matthew Wilcox
2017-12-19 19:42 ` Rao Shoaib
2017-12-19 19:30 ` Matthew Wilcox
2017-12-19 19:56 ` Rao Shoaib
2017-12-19 20:22 ` Paul E. McKenney
2017-12-19 19:33 ` Jesper Dangaard Brouer
2017-12-19 19:33 ` Christopher Lameter
2017-12-19 20:02 ` Rao Shoaib
2017-12-20 0:56 ` Christopher Lameter
2017-12-20 18:14 ` Jesper Dangaard Brouer
2017-12-20 14:17 ` Michal Hocko
2017-12-19 20:41 ` Jesper Dangaard Brouer
2017-12-19 20:56 ` Paul E. McKenney
2017-12-19 21:20 ` Rao Shoaib
2017-12-20 7:31 ` Jesper Dangaard Brouer [this message]
2017-12-19 22:12 ` Matthew Wilcox
2017-12-19 23:25 ` Rao Shoaib
2017-12-20 0:20 ` Paul E. McKenney
2017-12-20 1:53 ` Matthew Wilcox
2017-12-20 5:19 ` Paul E. McKenney
2017-12-20 7:06 ` Jesper Dangaard Brouer
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=20171220083121.4aaa8a2a@redhat.com \
--to=brouer@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=rao.shoaib@oracle.com \
/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