All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.