From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Rao Shoaib <rao.shoaib@oracle.com>
Cc: Matthew Wilcox <willy@infradead.org>,
linux-kernel@vger.kernel.org, brouer@redhat.com,
linux-mm@kvack.org
Subject: Re: [PATCH] kfree_rcu() should use the new kfree_bulk() interface for freeing rcu structures
Date: Tue, 19 Dec 2017 12:22:32 -0800 [thread overview]
Message-ID: <20171219202232.GE7829@linux.vnet.ibm.com> (raw)
In-Reply-To: <24c9f1c0-58d4-5d27-8795-d211693455dd@oracle.com>
On Tue, Dec 19, 2017 at 11:56:30AM -0800, Rao Shoaib wrote:
> On 12/19/2017 11:30 AM, Matthew Wilcox wrote:
> >On Tue, Dec 19, 2017 at 09:52:27AM -0800, rao.shoaib@oracle.com wrote:
[ . . . ]
> >I've been doing a lot of thinking about this because I really want a
> >way to kfree_rcu() an object without embedding a struct rcu_head in it.
> >But I see no way to do that today; even if we have an external memory
> >allocation to point to the object to be freed, we have to keep track of
> >the grace periods.
> I am not sure I understand. If you had external memory you can
> easily do that.
> I am exactly doing that, the only reason the RCU structure is needed
> is to get the pointer to the object being freed.
This can be done as long as you are willing to either:
1. Occasionally have kfree_rcu() wait for a grace period.
2. Occasionally have kfree_rcu() allocate memory.
3. Keep the rcu_head, but use it only when you would otherwise
have to accept the above two penalties. (The point of this
is that tracking lists of memory waiting for a grace period
using dense arrays improves cache locality.)
There might be others, and if you come up with one, please don't keep it
a secret. The C++ standards committee insisted on an interface using
option #2 above. (There is also an option to use their equivalent of
an rcu_head.)
Thanx, Paul
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Rao Shoaib <rao.shoaib@oracle.com>
Cc: Matthew Wilcox <willy@infradead.org>,
linux-kernel@vger.kernel.org, brouer@redhat.com,
linux-mm@kvack.org
Subject: Re: [PATCH] kfree_rcu() should use the new kfree_bulk() interface for freeing rcu structures
Date: Tue, 19 Dec 2017 12:22:32 -0800 [thread overview]
Message-ID: <20171219202232.GE7829@linux.vnet.ibm.com> (raw)
In-Reply-To: <24c9f1c0-58d4-5d27-8795-d211693455dd@oracle.com>
On Tue, Dec 19, 2017 at 11:56:30AM -0800, Rao Shoaib wrote:
> On 12/19/2017 11:30 AM, Matthew Wilcox wrote:
> >On Tue, Dec 19, 2017 at 09:52:27AM -0800, rao.shoaib@oracle.com wrote:
[ . . . ]
> >I've been doing a lot of thinking about this because I really want a
> >way to kfree_rcu() an object without embedding a struct rcu_head in it.
> >But I see no way to do that today; even if we have an external memory
> >allocation to point to the object to be freed, we have to keep track of
> >the grace periods.
> I am not sure I understand. If you had external memory you can
> easily do that.
> I am exactly doing that, the only reason the RCU structure is needed
> is to get the pointer to the object being freed.
This can be done as long as you are willing to either:
1. Occasionally have kfree_rcu() wait for a grace period.
2. Occasionally have kfree_rcu() allocate memory.
3. Keep the rcu_head, but use it only when you would otherwise
have to accept the above two penalties. (The point of this
is that tracking lists of memory waiting for a grace period
using dense arrays improves cache locality.)
There might be others, and if you come up with one, please don't keep it
a secret. The C++ standards committee insisted on an interface using
option #2 above. (There is also an option to use their equivalent of
an rcu_head.)
Thanx, Paul
next prev parent reply other threads:[~2017-12-19 20:22 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-19 17:52 [PATCH] kfree_rcu() should use the new kfree_bulk() interface for freeing rcu structures rao.shoaib
2017-12-19 17:52 ` rao.shoaib
2017-12-19 19:12 ` Matthew Wilcox
2017-12-19 19:12 ` Matthew Wilcox
2017-12-19 19:42 ` Rao Shoaib
2017-12-19 19:42 ` Rao Shoaib
2017-12-19 19:30 ` Matthew Wilcox
2017-12-19 19:30 ` Matthew Wilcox
2017-12-19 19:56 ` Rao Shoaib
2017-12-19 19:56 ` Rao Shoaib
2017-12-19 20:22 ` Paul E. McKenney [this message]
2017-12-19 20:22 ` Paul E. McKenney
2017-12-19 19:33 ` Jesper Dangaard Brouer
2017-12-19 19:33 ` Jesper Dangaard Brouer
2017-12-19 19:33 ` Christopher Lameter
2017-12-19 19:33 ` Christopher Lameter
2017-12-19 20:02 ` Rao Shoaib
2017-12-19 20:02 ` Rao Shoaib
2017-12-20 0:56 ` Christopher Lameter
2017-12-20 0:56 ` Christopher Lameter
2017-12-20 18:14 ` Jesper Dangaard Brouer
2017-12-20 18:14 ` Jesper Dangaard Brouer
2017-12-20 14:17 ` Michal Hocko
2017-12-20 14:17 ` Michal Hocko
2017-12-19 20:41 ` Jesper Dangaard Brouer
2017-12-19 20:41 ` Jesper Dangaard Brouer
2017-12-19 20:56 ` Paul E. McKenney
2017-12-19 20:56 ` Paul E. McKenney
2017-12-19 21:20 ` Rao Shoaib
2017-12-19 21:20 ` Rao Shoaib
2017-12-20 7:31 ` Jesper Dangaard Brouer
2017-12-20 7:31 ` Jesper Dangaard Brouer
2017-12-19 22:12 ` Matthew Wilcox
2017-12-19 22:12 ` Matthew Wilcox
2017-12-19 23:25 ` Rao Shoaib
2017-12-19 23:25 ` Rao Shoaib
2017-12-20 0:20 ` Paul E. McKenney
2017-12-20 0:20 ` Paul E. McKenney
2017-12-20 1:53 ` Matthew Wilcox
2017-12-20 1:53 ` Matthew Wilcox
2017-12-20 5:19 ` Paul E. McKenney
2017-12-20 5:19 ` Paul E. McKenney
2017-12-20 7:06 ` Jesper Dangaard Brouer
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=20171219202232.GE7829@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=brouer@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=rao.shoaib@oracle.com \
--cc=willy@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.