All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jesper Dangaard Brouer <brouer@redhat.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Kirill Tkhai <ktkhai@virtuozzo.com>,
	Matthew Wilcox <willy@infradead.org>,
	josh@joshtriplett.org, mathieu.desnoyers@efficios.com,
	jiangshanlai@gmail.com, mingo@redhat.com, cl@linux.com,
	penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com,
	akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, rao.shoaib@oracle.com, brouer@redhat.com
Subject: Re: [PATCH 0/2] rcu: Transform kfree_rcu() into kvfree_rcu()
Date: Wed, 7 Feb 2018 17:45:13 +0100	[thread overview]
Message-ID: <20180207174513.5cc9b503@redhat.com> (raw)
In-Reply-To: <20180207085700.393f90d0@gandalf.local.home>

On Wed, 7 Feb 2018 08:57:00 -0500
Steven Rostedt <rostedt@goodmis.org> wrote:

> On Wed, 7 Feb 2018 00:31:04 -0800
> "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
> 
> > I see problems.  We would then have two different names for exactly the
> > same thing.
> > 
> > Seems like it would be a lot easier to simply document the existing
> > kfree_rcu() behavior, especially given that it apparently already works.
> > The really doesn't seem to me to be worth a name change.  
> 
> Honestly, I don't believe this is an RCU sub-system decision. This is a
> memory management decision.
> 
> If we have kmalloc(), vmalloc(), kfree(), vfree() and kvfree(), and we
> want kmalloc() to be freed with kfree(), and vmalloc() to be freed with
> vfree(), and for strange reasons, we don't know how the data was
> allocated we have kvfree(). That's an mm decision not an rcu one. We
> should have kfree_rcu(), vfree_rcu() and kvfree_rcu(), and honestly,
> they should not depend on kvfree() doing the same thing for everything.
> Each should call the corresponding member that they represent. Which
> would change this patch set.
> 
> Why? Too much coupling between RCU and MM. What if in the future
> something changes and kvfree() goes away or changes drastically. We
> would then have to go through all the users of RCU to change them too.
> 
> To me kvfree() is a special case and should not be used by RCU as a
> generic function. That would make RCU and MM much more coupled than
> necessary.

For the record, I fully agree with Steve here. 

And being a performance "fanatic" I don't like to have the extra branch
(and compares) in the free code path... but it's a MM-decision (and
sometimes you should not listen to "fanatics" ;-))

void kvfree(const void *addr)
{
	if (is_vmalloc_addr(addr))
		vfree(addr);
	else
		kfree(addr);
}
EXPORT_SYMBOL(kvfree);

-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  LinkedIn: http://www.linkedin.com/in/brouer


static inline bool is_vmalloc_addr(const void *x)
{
#ifdef CONFIG_MMU
	unsigned long addr = (unsigned long)x;

	return addr >= VMALLOC_START && addr < VMALLOC_END;
#else
	return false;
#endif
}

--
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: Jesper Dangaard Brouer <brouer@redhat.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Kirill Tkhai <ktkhai@virtuozzo.com>,
	Matthew Wilcox <willy@infradead.org>,
	josh@joshtriplett.org, mathieu.desnoyers@efficios.com,
	jiangshanlai@gmail.com, mingo@redhat.com, cl@linux.com,
	penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com,
	akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, rao.shoaib@oracle.com, brouer@redhat.com
Subject: Re: [PATCH 0/2] rcu: Transform kfree_rcu() into kvfree_rcu()
Date: Wed, 7 Feb 2018 17:45:13 +0100	[thread overview]
Message-ID: <20180207174513.5cc9b503@redhat.com> (raw)
In-Reply-To: <20180207085700.393f90d0@gandalf.local.home>

On Wed, 7 Feb 2018 08:57:00 -0500
Steven Rostedt <rostedt@goodmis.org> wrote:

> On Wed, 7 Feb 2018 00:31:04 -0800
> "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
> 
> > I see problems.  We would then have two different names for exactly the
> > same thing.
> > 
> > Seems like it would be a lot easier to simply document the existing
> > kfree_rcu() behavior, especially given that it apparently already works.
> > The really doesn't seem to me to be worth a name change.  
> 
> Honestly, I don't believe this is an RCU sub-system decision. This is a
> memory management decision.
> 
> If we have kmalloc(), vmalloc(), kfree(), vfree() and kvfree(), and we
> want kmalloc() to be freed with kfree(), and vmalloc() to be freed with
> vfree(), and for strange reasons, we don't know how the data was
> allocated we have kvfree(). That's an mm decision not an rcu one. We
> should have kfree_rcu(), vfree_rcu() and kvfree_rcu(), and honestly,
> they should not depend on kvfree() doing the same thing for everything.
> Each should call the corresponding member that they represent. Which
> would change this patch set.
> 
> Why? Too much coupling between RCU and MM. What if in the future
> something changes and kvfree() goes away or changes drastically. We
> would then have to go through all the users of RCU to change them too.
> 
> To me kvfree() is a special case and should not be used by RCU as a
> generic function. That would make RCU and MM much more coupled than
> necessary.

For the record, I fully agree with Steve here. 

And being a performance "fanatic" I don't like to have the extra branch
(and compares) in the free code path... but it's a MM-decision (and
sometimes you should not listen to "fanatics" ;-))

void kvfree(const void *addr)
{
	if (is_vmalloc_addr(addr))
		vfree(addr);
	else
		kfree(addr);
}
EXPORT_SYMBOL(kvfree);

-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  LinkedIn: http://www.linkedin.com/in/brouer


static inline bool is_vmalloc_addr(const void *x)
{
#ifdef CONFIG_MMU
	unsigned long addr = (unsigned long)x;

	return addr >= VMALLOC_START && addr < VMALLOC_END;
#else
	return false;
#endif
}

  parent reply	other threads:[~2018-02-07 16:45 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-06 10:19 [PATCH 0/2] rcu: Transform kfree_rcu() into kvfree_rcu() Kirill Tkhai
2018-02-06 10:19 ` Kirill Tkhai
2018-02-06 10:19 ` [PATCH 1/2] " Kirill Tkhai
2018-02-06 10:19   ` Kirill Tkhai
2018-02-06 14:34   ` Steven Rostedt
2018-02-06 14:34     ` Steven Rostedt
2018-02-06 15:06     ` Kirill Tkhai
2018-02-06 15:06       ` Kirill Tkhai
2018-02-06 15:49       ` Steven Rostedt
2018-02-06 15:49         ` Steven Rostedt
2018-02-06 10:19 ` [PATCH 2/2] mm: Use kvfree_rcu() in update_memcg_params() Kirill Tkhai
2018-02-06 10:19   ` Kirill Tkhai
2018-02-07  2:17 ` [PATCH 0/2] rcu: Transform kfree_rcu() into kvfree_rcu() Paul E. McKenney
2018-02-07  2:17   ` Paul E. McKenney
2018-02-07  4:23   ` Matthew Wilcox
2018-02-07  4:23     ` Matthew Wilcox
2018-02-07  5:02     ` Paul E. McKenney
2018-02-07  5:02       ` Paul E. McKenney
2018-02-07  7:54       ` Josh Triplett
2018-02-07  7:54         ` Josh Triplett
2018-02-07  8:20         ` Paul E. McKenney
2018-02-07  8:20           ` Paul E. McKenney
2018-02-07  7:57       ` Kirill Tkhai
2018-02-07  7:57         ` Kirill Tkhai
2018-02-07  8:31         ` Paul E. McKenney
2018-02-07  8:31           ` Paul E. McKenney
2018-02-07 13:57           ` Steven Rostedt
2018-02-07 13:57             ` Steven Rostedt
2018-02-07 16:18             ` Matthew Wilcox
2018-02-07 16:18               ` Matthew Wilcox
2018-02-07 16:34               ` Steven Rostedt
2018-02-07 16:34                 ` Steven Rostedt
2018-02-07 16:45             ` Jesper Dangaard Brouer [this message]
2018-02-07 16:45               ` Jesper Dangaard Brouer
2018-02-07 18:10               ` Matthew Wilcox
2018-02-07 18:10                 ` Matthew Wilcox
2018-02-07 18:26                 ` Steven Rostedt
2018-02-07 18:26                   ` Steven Rostedt
2018-02-08  4:10                   ` Paul E. McKenney
2018-02-08  4:10                     ` Paul E. McKenney
2018-02-22 23:55                 ` Paul E. McKenney
2018-02-22 23:55                   ` Paul E. McKenney
2018-02-08  4:09             ` Paul E. McKenney
2018-02-08  4:09               ` Paul E. McKenney
2018-02-07 16:47     ` Christopher Lameter
2018-02-07 16:47       ` Christopher Lameter
2018-02-07 17:09       ` Steven Rostedt
2018-02-07 17:09         ` Steven Rostedt
2018-02-07 17:19         ` Matthew Wilcox
2018-02-07 17:19           ` Matthew Wilcox
2018-02-07 17:29           ` Steven Rostedt
2018-02-07 17:29             ` Steven Rostedt
2018-02-07 17:54             ` Christopher Lameter
2018-02-07 17:54               ` Christopher Lameter
2018-02-07 14:55   ` Christopher Lameter
2018-02-07 14:55     ` Christopher Lameter
2018-02-08  4:09     ` Paul E. McKenney
2018-02-08  4:09       ` Paul E. McKenney

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=20180207174513.5cc9b503@redhat.com \
    --to=brouer@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=jiangshanlai@gmail.com \
    --cc=josh@joshtriplett.org \
    --cc=ktkhai@virtuozzo.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mingo@redhat.com \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=penberg@kernel.org \
    --cc=rao.shoaib@oracle.com \
    --cc=rientjes@google.com \
    --cc=rostedt@goodmis.org \
    --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.