From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl0-f71.google.com (mail-pl0-f71.google.com [209.85.160.71]) by kanga.kvack.org (Postfix) with ESMTP id AB15A6B0003 for ; Tue, 6 Feb 2018 05:19:46 -0500 (EST) Received: by mail-pl0-f71.google.com with SMTP id f4so1383113plr.14 for ; Tue, 06 Feb 2018 02:19:46 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0105.outbound.protection.outlook.com. [104.47.0.105]) by mx.google.com with ESMTPS id j63si6696644pgc.591.2018.02.06.02.19.44 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 06 Feb 2018 02:19:45 -0800 (PST) Subject: [PATCH 0/2] rcu: Transform kfree_rcu() into kvfree_rcu() From: Kirill Tkhai Date: Tue, 06 Feb 2018 13:19:29 +0300 Message-ID: <151791170164.5994.8253310844733420079.stgit@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: paulmck@linux.vnet.ibm.com, josh@joshtriplett.org, rostedt@goodmis.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, ktkhai@virtuozzo.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org Recent times kvmalloc() begun widely be used in kernel. Some of such memory allocations have to be freed after rcu grace period, and this patchset introduces a generic primitive for doing this. Actually, everything is made in [1/2]. Patch [2/2] is just added to make new kvfree_rcu() have the first user. The patch [1/2] transforms kfree_rcu(), its sub definitions and its sub functions into kvfree_rcu() form. The most significant change is in __rcu_reclaim(), where kvfree() is used instead of kfree(). Since kvfree() is able to have a deal with memory allocated via kmalloc(), vmalloc() and kvmalloc(); kfree_rcu() and vfree_rcu() may simply be defined through this new kvfree_rcu(). --- Kirill Tkhai (2): rcu: Transform kfree_rcu() into kvfree_rcu() mm: Use kvfree_rcu() in update_memcg_params() include/linux/rcupdate.h | 31 +++++++++++++++++-------------- include/linux/rcutiny.h | 4 ++-- include/linux/rcutree.h | 2 +- include/trace/events/rcu.h | 12 ++++++------ kernel/rcu/rcu.h | 8 ++++---- kernel/rcu/tree.c | 14 +++++++------- kernel/rcu/tree_plugin.h | 10 +++++----- mm/slab_common.c | 10 +--------- 8 files changed, 43 insertions(+), 48 deletions(-) -- Signed-off-by: Kirill Tkhai -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg0-f69.google.com (mail-pg0-f69.google.com [74.125.83.69]) by kanga.kvack.org (Postfix) with ESMTP id C067A6B0008 for ; Tue, 6 Feb 2018 05:19:58 -0500 (EST) Received: by mail-pg0-f69.google.com with SMTP id m3so1221881pgd.20 for ; Tue, 06 Feb 2018 02:19:58 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0104.outbound.protection.outlook.com. [104.47.0.104]) by mx.google.com with ESMTPS id h15-v6si1514865pli.212.2018.02.06.02.19.56 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 06 Feb 2018 02:19:57 -0800 (PST) Subject: [PATCH 1/2] rcu: Transform kfree_rcu() into kvfree_rcu() From: Kirill Tkhai Date: Tue, 06 Feb 2018 13:19:45 +0300 Message-ID: <151791238553.5994.4933976056810745303.stgit@localhost.localdomain> In-Reply-To: <151791170164.5994.8253310844733420079.stgit@localhost.localdomain> References: <151791170164.5994.8253310844733420079.stgit@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: paulmck@linux.vnet.ibm.com, josh@joshtriplett.org, rostedt@goodmis.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, ktkhai@virtuozzo.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org Recent times kvmalloc() begun widely be used in kernel. Some of such memory allocations have to be freed after rcu grace period, and this patch introduces a generic primitive for doing this. Currently, there is kfree_rcu() primitive in kernel, which encodes rcu_head offset inside freed structure on place of callback function. We can simply reuse it and replace final kfree() in __rcu_reclaim() with kvfree(). Since this primitive is able to free memory allocated via kmalloc(), vmalloc() and kvmalloc(), we may have single kvfree_rcu(), and define kfree_rcu() and vfree_rcu() through it. This allows users to avoid to implement custom functions for destruction kvmalloc()'ed and vmalloc()'ed memory. The new primitive kvfree_rcu() are used since next patch. Signed-off-by: Kirill Tkhai --- include/linux/rcupdate.h | 31 +++++++++++++++++-------------- include/linux/rcutiny.h | 4 ++-- include/linux/rcutree.h | 2 +- include/trace/events/rcu.h | 12 ++++++------ kernel/rcu/rcu.h | 8 ++++---- kernel/rcu/tree.c | 14 +++++++------- kernel/rcu/tree_plugin.h | 10 +++++----- 7 files changed, 42 insertions(+), 39 deletions(-) diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h index 043d04784675..22d4086f50b2 100644 --- a/include/linux/rcupdate.h +++ b/include/linux/rcupdate.h @@ -832,36 +832,36 @@ static inline notrace void rcu_read_unlock_sched_notrace(void) /* * Does the specified offset indicate that the corresponding rcu_head - * structure can be handled by kfree_rcu()? + * structure can be handled by kvfree_rcu()? */ -#define __is_kfree_rcu_offset(offset) ((offset) < 4096) +#define __is_kvfree_rcu_offset(offset) ((offset) < 4096) /* - * Helper macro for kfree_rcu() to prevent argument-expansion eyestrain. + * Helper macro for kvfree_rcu() to prevent argument-expansion eyestrain. */ -#define __kfree_rcu(head, offset) \ +#define __kvfree_rcu(head, offset) \ do { \ - BUILD_BUG_ON(!__is_kfree_rcu_offset(offset)); \ - kfree_call_rcu(head, (rcu_callback_t)(unsigned long)(offset)); \ + BUILD_BUG_ON(!__is_kvfree_rcu_offset(offset)); \ + kvfree_call_rcu(head, (rcu_callback_t)(unsigned long)(offset)); \ } while (0) /** - * kfree_rcu() - kfree an object after a grace period. - * @ptr: pointer to kfree + * kvfree_rcu() - kvfree an object after a grace period. + * @ptr: pointer to kvfree * @rcu_head: the name of the struct rcu_head within the type of @ptr. * - * Many rcu callbacks functions just call kfree() on the base structure. + * Many rcu callbacks functions just call kvfree() on the base structure. * These functions are trivial, but their size adds up, and furthermore * when they are used in a kernel module, that module must invoke the * high-latency rcu_barrier() function at module-unload time. * - * The kfree_rcu() function handles this issue. Rather than encoding a - * function address in the embedded rcu_head structure, kfree_rcu() instead + * The kvfree_rcu() function handles this issue. Rather than encoding a + * function address in the embedded rcu_head structure, kvfree_rcu() instead * encodes the offset of the rcu_head structure within the base structure. * Because the functions are not allowed in the low-order 4096 bytes of * kernel virtual memory, offsets up to 4095 bytes can be accommodated. * If the offset is larger than 4095 bytes, a compile-time error will - * be generated in __kfree_rcu(). If this error is triggered, you can + * be generated in __kvfree_rcu(). If this error is triggered, you can * either fall back to use of call_rcu() or rearrange the structure to * position the rcu_head structure into the first 4096 bytes. * @@ -871,9 +871,12 @@ static inline notrace void rcu_read_unlock_sched_notrace(void) * The BUILD_BUG_ON check must not involve any function calls, hence the * checks are done in macros here. */ -#define kfree_rcu(ptr, rcu_head) \ - __kfree_rcu(&((ptr)->rcu_head), offsetof(typeof(*(ptr)), rcu_head)) +#define kvfree_rcu(ptr, rcu_head) \ + __kvfree_rcu(&((ptr)->rcu_head), offsetof(typeof(*(ptr)), rcu_head)) +#define kfree_rcu(ptr, rcu_head) kvfree_rcu(ptr, rcu_head) + +#define vfree_rcu(ptr, rcu_head) kvfree_rcu(ptr, rcu_head) /* * Place this after a lock-acquisition primitive to guarantee that diff --git a/include/linux/rcutiny.h b/include/linux/rcutiny.h index ce9beec35e34..2e484aaa534f 100644 --- a/include/linux/rcutiny.h +++ b/include/linux/rcutiny.h @@ -84,8 +84,8 @@ static inline void synchronize_sched_expedited(void) synchronize_sched(); } -static inline void kfree_call_rcu(struct rcu_head *head, - rcu_callback_t func) +static inline void kvfree_call_rcu(struct rcu_head *head, + rcu_callback_t func) { call_rcu(head, func); } diff --git a/include/linux/rcutree.h b/include/linux/rcutree.h index fd996cdf1833..4d6365be4504 100644 --- a/include/linux/rcutree.h +++ b/include/linux/rcutree.h @@ -48,7 +48,7 @@ void synchronize_rcu_bh(void); void synchronize_sched_expedited(void); void synchronize_rcu_expedited(void); -void kfree_call_rcu(struct rcu_head *head, rcu_callback_t func); +void kvfree_call_rcu(struct rcu_head *head, rcu_callback_t func); /** * synchronize_rcu_bh_expedited - Brute-force RCU-bh grace period diff --git a/include/trace/events/rcu.h b/include/trace/events/rcu.h index 0b50fda80db0..9507264fa8f8 100644 --- a/include/trace/events/rcu.h +++ b/include/trace/events/rcu.h @@ -496,13 +496,13 @@ TRACE_EVENT(rcu_callback, /* * Tracepoint for the registration of a single RCU callback of the special - * kfree() form. The first argument is the RCU type, the second argument + * kvfree() form. The first argument is the RCU type, the second argument * is a pointer to the RCU callback, the third argument is the offset * of the callback within the enclosing RCU-protected data structure, * the fourth argument is the number of lazy callbacks queued, and the * fifth argument is the total number of callbacks queued. */ -TRACE_EVENT(rcu_kfree_callback, +TRACE_EVENT(rcu_kvfree_callback, TP_PROTO(const char *rcuname, struct rcu_head *rhp, unsigned long offset, long qlen_lazy, long qlen), @@ -591,12 +591,12 @@ TRACE_EVENT(rcu_invoke_callback, /* * Tracepoint for the invocation of a single RCU callback of the special - * kfree() form. The first argument is the RCU flavor, the second + * kvfree() form. The first argument is the RCU flavor, the second * argument is a pointer to the RCU callback, and the third argument * is the offset of the callback within the enclosing RCU-protected * data structure. */ -TRACE_EVENT(rcu_invoke_kfree_callback, +TRACE_EVENT(rcu_invoke_kvfree_callback, TP_PROTO(const char *rcuname, struct rcu_head *rhp, unsigned long offset), @@ -767,12 +767,12 @@ TRACE_EVENT(rcu_barrier, #define trace_rcu_fqs(rcuname, gpnum, cpu, qsevent) do { } while (0) #define trace_rcu_dyntick(polarity, oldnesting, newnesting, dyntick) do { } while (0) #define trace_rcu_callback(rcuname, rhp, qlen_lazy, qlen) do { } while (0) -#define trace_rcu_kfree_callback(rcuname, rhp, offset, qlen_lazy, qlen) \ +#define trace_rcu_kvfree_callback(rcuname, rhp, offset, qlen_lazy, qlen) \ do { } while (0) #define trace_rcu_batch_start(rcuname, qlen_lazy, qlen, blimit) \ do { } while (0) #define trace_rcu_invoke_callback(rcuname, rhp) do { } while (0) -#define trace_rcu_invoke_kfree_callback(rcuname, rhp, offset) do { } while (0) +#define trace_rcu_invoke_kvfree_callback(rcuname, rhp, offset) do { } while (0) #define trace_rcu_batch_end(rcuname, callbacks_invoked, cb, nr, iit, risk) \ do { } while (0) #define trace_rcu_torture_read(rcutorturename, rhp, secs, c_old, c) \ diff --git a/kernel/rcu/rcu.h b/kernel/rcu/rcu.h index 6334f2c1abd0..696200886098 100644 --- a/kernel/rcu/rcu.h +++ b/kernel/rcu/rcu.h @@ -151,7 +151,7 @@ static inline void debug_rcu_head_unqueue(struct rcu_head *head) } #endif /* #else !CONFIG_DEBUG_OBJECTS_RCU_HEAD */ -void kfree(const void *); +void kvfree(const void *); /* * Reclaim the specified callback, either by invoking it (non-lazy case) @@ -162,9 +162,9 @@ static inline bool __rcu_reclaim(const char *rn, struct rcu_head *head) unsigned long offset = (unsigned long)head->func; rcu_lock_acquire(&rcu_callback_map); - if (__is_kfree_rcu_offset(offset)) { - RCU_TRACE(trace_rcu_invoke_kfree_callback(rn, head, offset);) - kfree((void *)head - offset); + if (__is_kvfree_rcu_offset(offset)) { + RCU_TRACE(trace_rcu_invoke_kvfree_callback(rn, head, offset);) + kvfree((void *)head - offset); rcu_lock_release(&rcu_callback_map); return true; } else { diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index 491bdf39f276..8e736aa11a46 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -3061,10 +3061,10 @@ __call_rcu(struct rcu_head *head, rcu_callback_t func, if (!lazy) rcu_idle_count_callbacks_posted(); - if (__is_kfree_rcu_offset((unsigned long)func)) - trace_rcu_kfree_callback(rsp->name, head, (unsigned long)func, - rcu_segcblist_n_lazy_cbs(&rdp->cblist), - rcu_segcblist_n_cbs(&rdp->cblist)); + if (__is_kvfree_rcu_offset((unsigned long)func)) + trace_rcu_kvfree_callback(rsp->name, head, (unsigned long)func, + rcu_segcblist_n_lazy_cbs(&rdp->cblist), + rcu_segcblist_n_cbs(&rdp->cblist)); else trace_rcu_callback(rsp->name, head, rcu_segcblist_n_lazy_cbs(&rdp->cblist), @@ -3134,14 +3134,14 @@ EXPORT_SYMBOL_GPL(call_rcu_bh); * This will likely be later named something like "call_rcu_lazy()", * but this change will require some way of tagging the lazy RCU * callbacks in the list of pending callbacks. Until then, this - * function may only be called from __kfree_rcu(). + * function may only be called from __kvfree_rcu(). */ -void kfree_call_rcu(struct rcu_head *head, +void kvfree_call_rcu(struct rcu_head *head, rcu_callback_t func) { __call_rcu(head, func, rcu_state_p, -1, 1); } -EXPORT_SYMBOL_GPL(kfree_call_rcu); +EXPORT_SYMBOL_GPL(kvfree_call_rcu); /* * Because a context switch is a grace period for RCU-sched and RCU-bh, diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h index fb88a028deec..85715963658e 100644 --- a/kernel/rcu/tree_plugin.h +++ b/kernel/rcu/tree_plugin.h @@ -1984,11 +1984,11 @@ static bool __call_rcu_nocb(struct rcu_data *rdp, struct rcu_head *rhp, if (!rcu_is_nocb_cpu(rdp->cpu)) return false; __call_rcu_nocb_enqueue(rdp, rhp, &rhp->next, 1, lazy, flags); - if (__is_kfree_rcu_offset((unsigned long)rhp->func)) - trace_rcu_kfree_callback(rdp->rsp->name, rhp, - (unsigned long)rhp->func, - -atomic_long_read(&rdp->nocb_q_count_lazy), - -atomic_long_read(&rdp->nocb_q_count)); + if (__is_kvfree_rcu_offset((unsigned long)rhp->func)) + trace_rcu_kvfree_callback(rdp->rsp->name, rhp, + (unsigned long)rhp->func, + -atomic_long_read(&rdp->nocb_q_count_lazy), + -atomic_long_read(&rdp->nocb_q_count)); else trace_rcu_callback(rdp->rsp->name, rhp, -atomic_long_read(&rdp->nocb_q_count_lazy), -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f197.google.com (mail-pf0-f197.google.com [209.85.192.197]) by kanga.kvack.org (Postfix) with ESMTP id 9949A6B0009 for ; Tue, 6 Feb 2018 05:20:06 -0500 (EST) Received: by mail-pf0-f197.google.com with SMTP id y13so732739pfl.16 for ; Tue, 06 Feb 2018 02:20:06 -0800 (PST) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20122.outbound.protection.outlook.com. [40.107.2.122]) by mx.google.com with ESMTPS id v22si1335982pfd.22.2018.02.06.02.20.05 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 06 Feb 2018 02:20:05 -0800 (PST) Subject: [PATCH 2/2] mm: Use kvfree_rcu() in update_memcg_params() From: Kirill Tkhai Date: Tue, 06 Feb 2018 13:19:56 +0300 Message-ID: <151791239671.5994.2058061081618636334.stgit@localhost.localdomain> In-Reply-To: <151791170164.5994.8253310844733420079.stgit@localhost.localdomain> References: <151791170164.5994.8253310844733420079.stgit@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: paulmck@linux.vnet.ibm.com, josh@joshtriplett.org, rostedt@goodmis.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, ktkhai@virtuozzo.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org Make update_memcg_params() to use generic kvfree_rcu() helper and remove free_memcg_params() code. Signed-off-by: Kirill Tkhai --- mm/slab_common.c | 10 +--------- 1 file changed, 1 insertion(+), 9 deletions(-) diff --git a/mm/slab_common.c b/mm/slab_common.c index 10f127b2de7c..92d4a3a9471d 100644 --- a/mm/slab_common.c +++ b/mm/slab_common.c @@ -190,14 +190,6 @@ static void destroy_memcg_params(struct kmem_cache *s) kvfree(rcu_access_pointer(s->memcg_params.memcg_caches)); } -static void free_memcg_params(struct rcu_head *rcu) -{ - struct memcg_cache_array *old; - - old = container_of(rcu, struct memcg_cache_array, rcu); - kvfree(old); -} - static int update_memcg_params(struct kmem_cache *s, int new_array_size) { struct memcg_cache_array *old, *new; @@ -215,7 +207,7 @@ static int update_memcg_params(struct kmem_cache *s, int new_array_size) rcu_assign_pointer(s->memcg_params.memcg_caches, new); if (old) - call_rcu(&old->rcu, free_memcg_params); + kvfree_rcu(old, rcu); return 0; } -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl0-f70.google.com (mail-pl0-f70.google.com [209.85.160.70]) by kanga.kvack.org (Postfix) with ESMTP id 0E3AA6B0006 for ; Tue, 6 Feb 2018 09:34:56 -0500 (EST) Received: by mail-pl0-f70.google.com with SMTP id f1so1752871plb.7 for ; Tue, 06 Feb 2018 06:34:56 -0800 (PST) Received: from mail.kernel.org (mail.kernel.org. [198.145.29.99]) by mx.google.com with ESMTPS id p12si17294pgn.253.2018.02.06.06.34.54 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Feb 2018 06:34:54 -0800 (PST) Date: Tue, 6 Feb 2018 09:34:51 -0500 From: Steven Rostedt Subject: Re: [PATCH 1/2] rcu: Transform kfree_rcu() into kvfree_rcu() Message-ID: <20180206093451.0de5ceeb@gandalf.local.home> In-Reply-To: <151791238553.5994.4933976056810745303.stgit@localhost.localdomain> References: <151791170164.5994.8253310844733420079.stgit@localhost.localdomain> <151791238553.5994.4933976056810745303.stgit@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Kirill Tkhai Cc: paulmck@linux.vnet.ibm.com, 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 On Tue, 06 Feb 2018 13:19:45 +0300 Kirill Tkhai wrote: > /** > - * kfree_rcu() - kfree an object after a grace period. > - * @ptr: pointer to kfree > + * kvfree_rcu() - kvfree an object after a grace period. > + * @ptr: pointer to kvfree > * @rcu_head: the name of the struct rcu_head within the type of @ptr. > * You may want to add a big comment here that states this works for both free vmalloc and kmalloc data. Because if I saw this, I would think it only works for vmalloc, and start implementing a custom one for kmalloc data. -- Steve > - * Many rcu callbacks functions just call kfree() on the base structure. > + * Many rcu callbacks functions just call kvfree() on the base structure. > * These functions are trivial, but their size adds up, and furthermore > * when they are used in a kernel module, that module must invoke the > * high-latency rcu_barrier() function at module-unload time. > * > - * The kfree_rcu() function handles this issue. Rather than encoding a > - * function address in the embedded rcu_head structure, kfree_rcu() instead > + * The kvfree_rcu() function handles this issue. Rather than encoding a > + * function address in the embedded rcu_head structure, kvfree_rcu() instead > * encodes the offset of the rcu_head structure within the base structure. > * Because the functions are not allowed in the low-order 4096 bytes of > * kernel virtual memory, offsets up to 4095 bytes can be accommodated. > * If the offset is larger than 4095 bytes, a compile-time error will > - * be generated in __kfree_rcu(). If this error is triggered, you can > + * be generated in __kvfree_rcu(). If this error is triggered, you can > * either fall back to use of call_rcu() or rearrange the structure to > * position the rcu_head structure into the first 4096 bytes. > * > @@ -871,9 +871,12 @@ static inline notrace void rcu_read_unlock_sched_notrace(void) > * The BUILD_BUG_ON check must not involve any function calls, hence the > * checks are done in macros here. > */ > -#define kfree_rcu(ptr, rcu_head) \ > - __kfree_rcu(&((ptr)->rcu_head), offsetof(typeof(*(ptr)), rcu_head)) > +#define kvfree_rcu(ptr, rcu_head) \ > + __kvfree_rcu(&((ptr)->rcu_head), offsetof(typeof(*(ptr)), rcu_head)) > > +#define kfree_rcu(ptr, rcu_head) kvfree_rcu(ptr, rcu_head) > + > +#define vfree_rcu(ptr, rcu_head) kvfree_rcu(ptr, rcu_head) > > /* > * Place this after a lock-acquisition primitive to guarantee that > diff --git a/include/linux/rcutiny.h b/include/linux/rcutiny.h > index ce9beec35e34..2e484aaa534f 100644 > --- a/include/linux/rcutiny.h > +++ b/include/linux/rcutiny.h > @@ -84,8 +84,8 @@ static inline void synchronize_sched_expedited(void) > synchronize_sched(); > } > > -static inline void kfree_call_rcu(struct rcu_head *head, > - rcu_callback_t func) > +static inline void kvfree_call_rcu(struct rcu_head *head, > + rcu_callback_t func) > { > call_rcu(head, func); > } -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg0-f69.google.com (mail-pg0-f69.google.com [74.125.83.69]) by kanga.kvack.org (Postfix) with ESMTP id 2C1266B000C for ; Tue, 6 Feb 2018 10:06:43 -0500 (EST) Received: by mail-pg0-f69.google.com with SMTP id b6so1548815pgu.16 for ; Tue, 06 Feb 2018 07:06:43 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0131.outbound.protection.outlook.com. [104.47.1.131]) by mx.google.com with ESMTPS id o190si1892005pga.553.2018.02.06.07.06.40 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 06 Feb 2018 07:06:41 -0800 (PST) Subject: Re: [PATCH 1/2] rcu: Transform kfree_rcu() into kvfree_rcu() References: <151791170164.5994.8253310844733420079.stgit@localhost.localdomain> <151791238553.5994.4933976056810745303.stgit@localhost.localdomain> <20180206093451.0de5ceeb@gandalf.local.home> From: Kirill Tkhai Message-ID: <52fe3917-cf72-d512-8422-d53bacf40113@virtuozzo.com> Date: Tue, 6 Feb 2018 18:06:33 +0300 MIME-Version: 1.0 In-Reply-To: <20180206093451.0de5ceeb@gandalf.local.home> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Steven Rostedt Cc: paulmck@linux.vnet.ibm.com, 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 On 06.02.2018 17:34, Steven Rostedt wrote: > On Tue, 06 Feb 2018 13:19:45 +0300 > Kirill Tkhai wrote: > >> /** >> - * kfree_rcu() - kfree an object after a grace period. >> - * @ptr: pointer to kfree >> + * kvfree_rcu() - kvfree an object after a grace period. >> + * @ptr: pointer to kvfree >> * @rcu_head: the name of the struct rcu_head within the type of @ptr. >> * > > You may want to add a big comment here that states this works for both > free vmalloc and kmalloc data. Because if I saw this, I would think it > only works for vmalloc, and start implementing a custom one for kmalloc > data. There are kfree_rcu() and vfree_rcu() defined below, and they will give compilation error if someone tries to implement one more primitive with the same name. We may add a comment, but I'm not sure it will be good if people will use unpaired brackets like: obj = kmalloc(..) kvfree_rcu(obj,..) after they read such a commentary that it works for both vmalloc and kmalloc. After this unpaired behavior distribute over the kernel, we won't be able to implement some debug on top of this defines (I'm not sure it will be really need in the future, but anyway). Though, we may add a comment forcing use of paired bracket. Something like: /** * kvfree_rcu() - kvfree an object after a grace period. This is a primitive for objects allocated via kvmalloc*() family primitives. Do not use it to free kmalloc() and vmalloc() allocated objects, use kfree_rcu() and vfree_rcu() wrappers instead. How are you about this? Kirill >> - * Many rcu callbacks functions just call kfree() on the base structure. >> + * Many rcu callbacks functions just call kvfree() on the base structure. >> * These functions are trivial, but their size adds up, and furthermore >> * when they are used in a kernel module, that module must invoke the >> * high-latency rcu_barrier() function at module-unload time. >> * >> - * The kfree_rcu() function handles this issue. Rather than encoding a >> - * function address in the embedded rcu_head structure, kfree_rcu() instead >> + * The kvfree_rcu() function handles this issue. Rather than encoding a >> + * function address in the embedded rcu_head structure, kvfree_rcu() instead >> * encodes the offset of the rcu_head structure within the base structure. >> * Because the functions are not allowed in the low-order 4096 bytes of >> * kernel virtual memory, offsets up to 4095 bytes can be accommodated. >> * If the offset is larger than 4095 bytes, a compile-time error will >> - * be generated in __kfree_rcu(). If this error is triggered, you can >> + * be generated in __kvfree_rcu(). If this error is triggered, you can >> * either fall back to use of call_rcu() or rearrange the structure to >> * position the rcu_head structure into the first 4096 bytes. >> * >> @@ -871,9 +871,12 @@ static inline notrace void rcu_read_unlock_sched_notrace(void) >> * The BUILD_BUG_ON check must not involve any function calls, hence the >> * checks are done in macros here. >> */ >> -#define kfree_rcu(ptr, rcu_head) \ >> - __kfree_rcu(&((ptr)->rcu_head), offsetof(typeof(*(ptr)), rcu_head)) >> +#define kvfree_rcu(ptr, rcu_head) \ >> + __kvfree_rcu(&((ptr)->rcu_head), offsetof(typeof(*(ptr)), rcu_head)) >> >> +#define kfree_rcu(ptr, rcu_head) kvfree_rcu(ptr, rcu_head) >> + >> +#define vfree_rcu(ptr, rcu_head) kvfree_rcu(ptr, rcu_head) >> >> /* >> * Place this after a lock-acquisition primitive to guarantee that >> diff --git a/include/linux/rcutiny.h b/include/linux/rcutiny.h >> index ce9beec35e34..2e484aaa534f 100644 >> --- a/include/linux/rcutiny.h >> +++ b/include/linux/rcutiny.h >> @@ -84,8 +84,8 @@ static inline void synchronize_sched_expedited(void) >> synchronize_sched(); >> } >> >> -static inline void kfree_call_rcu(struct rcu_head *head, >> - rcu_callback_t func) >> +static inline void kvfree_call_rcu(struct rcu_head *head, >> + rcu_callback_t func) >> { >> call_rcu(head, func); >> } -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg0-f70.google.com (mail-pg0-f70.google.com [74.125.83.70]) by kanga.kvack.org (Postfix) with ESMTP id C62456B0011 for ; Tue, 6 Feb 2018 10:49:23 -0500 (EST) Received: by mail-pg0-f70.google.com with SMTP id q13so1594871pgt.17 for ; Tue, 06 Feb 2018 07:49:23 -0800 (PST) Received: from mail.kernel.org (mail.kernel.org. [198.145.29.99]) by mx.google.com with ESMTPS id b24-v6si151356pls.617.2018.02.06.07.49.22 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Feb 2018 07:49:22 -0800 (PST) Date: Tue, 6 Feb 2018 10:49:19 -0500 From: Steven Rostedt Subject: Re: [PATCH 1/2] rcu: Transform kfree_rcu() into kvfree_rcu() Message-ID: <20180206104919.0bc1734d@gandalf.local.home> In-Reply-To: <52fe3917-cf72-d512-8422-d53bacf40113@virtuozzo.com> References: <151791170164.5994.8253310844733420079.stgit@localhost.localdomain> <151791238553.5994.4933976056810745303.stgit@localhost.localdomain> <20180206093451.0de5ceeb@gandalf.local.home> <52fe3917-cf72-d512-8422-d53bacf40113@virtuozzo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Kirill Tkhai Cc: paulmck@linux.vnet.ibm.com, 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 On Tue, 6 Feb 2018 18:06:33 +0300 Kirill Tkhai wrote: > There are kfree_rcu() and vfree_rcu() defined below, and they will give > compilation error if someone tries to implement one more primitive with > the same name. Ah, I misread the patch. I was thinking you were simply replacing kfree_rcu() with kvfree_rcu(), but now see the macros added below it. > > We may add a comment, but I'm not sure it will be good if people will use > unpaired brackets like: > > obj = kmalloc(..) > kvfree_rcu(obj,..) > > after they read such a commentary that it works for both vmalloc and kmalloc. > After this unpaired behavior distribute over the kernel, we won't be able > to implement some debug on top of this defines (I'm not sure it will be really > need in the future, but anyway). > > Though, we may add a comment forcing use of paired bracket. Something like: > > /** > * kvfree_rcu() - kvfree an object after a grace period. > This is a primitive for objects allocated via kvmalloc*() family primitives. > Do not use it to free kmalloc() and vmalloc() allocated objects, use kfree_rcu() > and vfree_rcu() wrappers instead. > > How are you about this? Never mind, I missed the adding of kfree_rcu() at the bottom, and was thinking that we were just using kvfree_rcu() for everything. That's what I get for looking at patches before my first cup of coffee ;-) If you want to add a comment, feel free, but taking a second look, I don't feel it is necessary. -- Steve -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-f199.google.com (mail-qk0-f199.google.com [209.85.220.199]) by kanga.kvack.org (Postfix) with ESMTP id 2428A6B02B4 for ; Tue, 6 Feb 2018 21:17:01 -0500 (EST) Received: by mail-qk0-f199.google.com with SMTP id h138so3234555qke.8 for ; Tue, 06 Feb 2018 18:17:01 -0800 (PST) Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com. [148.163.156.1]) by mx.google.com with ESMTPS id y68si402821qkb.292.2018.02.06.18.16.59 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Feb 2018 18:17:00 -0800 (PST) Received: from pps.filterd (m0098410.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w172GHSw067239 for ; Tue, 6 Feb 2018 21:16:59 -0500 Received: from e19.ny.us.ibm.com (e19.ny.us.ibm.com [129.33.205.209]) by mx0a-001b2d01.pphosted.com with ESMTP id 2fyqhgj3wu-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Tue, 06 Feb 2018 21:16:58 -0500 Received: from localhost by e19.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 6 Feb 2018 21:16:57 -0500 Date: Tue, 6 Feb 2018 18:17:03 -0800 From: "Paul E. McKenney" Subject: Re: [PATCH 0/2] rcu: Transform kfree_rcu() into kvfree_rcu() Reply-To: paulmck@linux.vnet.ibm.com References: <151791170164.5994.8253310844733420079.stgit@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <151791170164.5994.8253310844733420079.stgit@localhost.localdomain> Message-Id: <20180207021703.GC3617@linux.vnet.ibm.com> Sender: owner-linux-mm@kvack.org List-ID: To: Kirill Tkhai Cc: josh@joshtriplett.org, rostedt@goodmis.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, brouer@redhat.com, rao.shoaib@oracle.com On Tue, Feb 06, 2018 at 01:19:29PM +0300, Kirill Tkhai wrote: > Recent times kvmalloc() begun widely be used in kernel. > Some of such memory allocations have to be freed after > rcu grace period, and this patchset introduces a generic > primitive for doing this. > > Actually, everything is made in [1/2]. Patch [2/2] is just > added to make new kvfree_rcu() have the first user. > > The patch [1/2] transforms kfree_rcu(), its sub definitions > and its sub functions into kvfree_rcu() form. The most > significant change is in __rcu_reclaim(), where kvfree() > is used instead of kfree(). Since kvfree() is able to > have a deal with memory allocated via kmalloc(), vmalloc() > and kvmalloc(); kfree_rcu() and vfree_rcu() may simply > be defined through this new kvfree_rcu(). Interesting. So it is OK to kvmalloc() something and pass it to either kfree() or kvfree(), and it had better be OK to kvmalloc() something and pass it to kvfree(). Is it OK to kmalloc() something and pass it to kvfree()? If so, is it really useful to have two different names here, that is, both kfree_rcu() and kvfree_rcu()? Also adding Jesper and Rao on CC for their awareness. Thanx, Paul > --- > > Kirill Tkhai (2): > rcu: Transform kfree_rcu() into kvfree_rcu() > mm: Use kvfree_rcu() in update_memcg_params() > > > include/linux/rcupdate.h | 31 +++++++++++++++++-------------- > include/linux/rcutiny.h | 4 ++-- > include/linux/rcutree.h | 2 +- > include/trace/events/rcu.h | 12 ++++++------ > kernel/rcu/rcu.h | 8 ++++---- > kernel/rcu/tree.c | 14 +++++++------- > kernel/rcu/tree_plugin.h | 10 +++++----- > mm/slab_common.c | 10 +--------- > 8 files changed, 43 insertions(+), 48 deletions(-) > > -- > Signed-off-by: Kirill Tkhai > -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg0-f70.google.com (mail-pg0-f70.google.com [74.125.83.70]) by kanga.kvack.org (Postfix) with ESMTP id 786676B02C2 for ; Tue, 6 Feb 2018 23:23:49 -0500 (EST) Received: by mail-pg0-f70.google.com with SMTP id b6so2511811pgu.16 for ; Tue, 06 Feb 2018 20:23:49 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org. [65.50.211.133]) by mx.google.com with ESMTPS id w8-v6si470203plk.597.2018.02.06.20.23.48 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 06 Feb 2018 20:23:48 -0800 (PST) Date: Tue, 6 Feb 2018 20:23:34 -0800 From: Matthew Wilcox Subject: Re: [PATCH 0/2] rcu: Transform kfree_rcu() into kvfree_rcu() Message-ID: <20180207042334.GA16175@bombadil.infradead.org> References: <151791170164.5994.8253310844733420079.stgit@localhost.localdomain> <20180207021703.GC3617@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180207021703.GC3617@linux.vnet.ibm.com> Sender: owner-linux-mm@kvack.org List-ID: To: "Paul E. McKenney" Cc: Kirill Tkhai , josh@joshtriplett.org, rostedt@goodmis.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, brouer@redhat.com, rao.shoaib@oracle.com On Tue, Feb 06, 2018 at 06:17:03PM -0800, Paul E. McKenney wrote: > So it is OK to kvmalloc() something and pass it to either kfree() or > kvfree(), and it had better be OK to kvmalloc() something and pass it > to kvfree(). > > Is it OK to kmalloc() something and pass it to kvfree()? Yes, it absolutely is. void kvfree(const void *addr) { if (is_vmalloc_addr(addr)) vfree(addr); else kfree(addr); } > If so, is it really useful to have two different names here, that is, > both kfree_rcu() and kvfree_rcu()? I think it's handy to have all three of kvfree_rcu(), kfree_rcu() and vfree_rcu() available in the API for the symmetry of calling kmalloc() / kfree_rcu(). Personally, I would like us to rename kvfree() to just free(), and have malloc(x) be an alias to kvmalloc(x, GFP_KERNEL), but I haven't won that fight yet. -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-f200.google.com (mail-qk0-f200.google.com [209.85.220.200]) by kanga.kvack.org (Postfix) with ESMTP id B55C16B02C6 for ; Wed, 7 Feb 2018 00:01:58 -0500 (EST) Received: by mail-qk0-f200.google.com with SMTP id y6so3515807qka.12 for ; Tue, 06 Feb 2018 21:01:58 -0800 (PST) Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com. [148.163.156.1]) by mx.google.com with ESMTPS id o62si655819qka.371.2018.02.06.21.01.57 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Feb 2018 21:01:57 -0800 (PST) Received: from pps.filterd (m0098393.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1751Hjt075776 for ; Wed, 7 Feb 2018 00:01:56 -0500 Received: from e16.ny.us.ibm.com (e16.ny.us.ibm.com [129.33.205.206]) by mx0a-001b2d01.pphosted.com with ESMTP id 2fyq0v7q6p-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Wed, 07 Feb 2018 00:01:56 -0500 Received: from localhost by e16.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 7 Feb 2018 00:01:55 -0500 Date: Tue, 6 Feb 2018 21:02:00 -0800 From: "Paul E. McKenney" Subject: Re: [PATCH 0/2] rcu: Transform kfree_rcu() into kvfree_rcu() Reply-To: paulmck@linux.vnet.ibm.com References: <151791170164.5994.8253310844733420079.stgit@localhost.localdomain> <20180207021703.GC3617@linux.vnet.ibm.com> <20180207042334.GA16175@bombadil.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180207042334.GA16175@bombadil.infradead.org> Message-Id: <20180207050200.GH3617@linux.vnet.ibm.com> Sender: owner-linux-mm@kvack.org List-ID: To: Matthew Wilcox Cc: Kirill Tkhai , josh@joshtriplett.org, rostedt@goodmis.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, brouer@redhat.com, rao.shoaib@oracle.com On Tue, Feb 06, 2018 at 08:23:34PM -0800, Matthew Wilcox wrote: > On Tue, Feb 06, 2018 at 06:17:03PM -0800, Paul E. McKenney wrote: > > So it is OK to kvmalloc() something and pass it to either kfree() or > > kvfree(), and it had better be OK to kvmalloc() something and pass it > > to kvfree(). > > > > Is it OK to kmalloc() something and pass it to kvfree()? > > Yes, it absolutely is. > > void kvfree(const void *addr) > { > if (is_vmalloc_addr(addr)) > vfree(addr); > else > kfree(addr); > } > > > If so, is it really useful to have two different names here, that is, > > both kfree_rcu() and kvfree_rcu()? > > I think it's handy to have all three of kvfree_rcu(), kfree_rcu() and > vfree_rcu() available in the API for the symmetry of calling kmalloc() > / kfree_rcu(). > > Personally, I would like us to rename kvfree() to just free(), and have > malloc(x) be an alias to kvmalloc(x, GFP_KERNEL), but I haven't won that > fight yet. But why not just have the existing kfree_rcu() API cover both kmalloc() and kvmalloc()? Perhaps I am not in the right forums, but I am not hearing anyone arguing that the RCU API has too few members. ;-) 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f71.google.com (mail-wm0-f71.google.com [74.125.82.71]) by kanga.kvack.org (Postfix) with ESMTP id 2556A6B02DD for ; Wed, 7 Feb 2018 02:54:20 -0500 (EST) Received: by mail-wm0-f71.google.com with SMTP id z83so370721wmc.5 for ; Tue, 06 Feb 2018 23:54:20 -0800 (PST) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net. [2001:4b98:c:538::195]) by mx.google.com with ESMTPS id j136si855965wmd.184.2018.02.06.23.54.18 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Feb 2018 23:54:18 -0800 (PST) Date: Tue, 6 Feb 2018 23:54:09 -0800 From: Josh Triplett Subject: Re: [PATCH 0/2] rcu: Transform kfree_rcu() into kvfree_rcu() Message-ID: <20180207075409.GA5726@localhost> References: <151791170164.5994.8253310844733420079.stgit@localhost.localdomain> <20180207021703.GC3617@linux.vnet.ibm.com> <20180207042334.GA16175@bombadil.infradead.org> <20180207050200.GH3617@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180207050200.GH3617@linux.vnet.ibm.com> Sender: owner-linux-mm@kvack.org List-ID: To: "Paul E. McKenney" Cc: Matthew Wilcox , Kirill Tkhai , rostedt@goodmis.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, brouer@redhat.com, rao.shoaib@oracle.com On Tue, Feb 06, 2018 at 09:02:00PM -0800, Paul E. McKenney wrote: > On Tue, Feb 06, 2018 at 08:23:34PM -0800, Matthew Wilcox wrote: > > On Tue, Feb 06, 2018 at 06:17:03PM -0800, Paul E. McKenney wrote: > > > So it is OK to kvmalloc() something and pass it to either kfree() or > > > kvfree(), and it had better be OK to kvmalloc() something and pass it > > > to kvfree(). > > > > > > Is it OK to kmalloc() something and pass it to kvfree()? > > > > Yes, it absolutely is. > > > > void kvfree(const void *addr) > > { > > if (is_vmalloc_addr(addr)) > > vfree(addr); > > else > > kfree(addr); > > } > > > > > If so, is it really useful to have two different names here, that is, > > > both kfree_rcu() and kvfree_rcu()? > > > > I think it's handy to have all three of kvfree_rcu(), kfree_rcu() and > > vfree_rcu() available in the API for the symmetry of calling kmalloc() > > / kfree_rcu(). > > > > Personally, I would like us to rename kvfree() to just free(), and have > > malloc(x) be an alias to kvmalloc(x, GFP_KERNEL), but I haven't won that > > fight yet. > > But why not just have the existing kfree_rcu() API cover both kmalloc() > and kvmalloc()? Perhaps I am not in the right forums, but I am not hearing > anyone arguing that the RCU API has too few members. ;-) I don't have any problem with having just `kvfree_rcu`, but having just `kfree_rcu` seems confusingly asymmetric. (Also, count me in favor of having just one "free" function, too.) -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg0-f69.google.com (mail-pg0-f69.google.com [74.125.83.69]) by kanga.kvack.org (Postfix) with ESMTP id 155A86B02DF for ; Wed, 7 Feb 2018 02:57:39 -0500 (EST) Received: by mail-pg0-f69.google.com with SMTP id k6so2753848pgt.15 for ; Tue, 06 Feb 2018 23:57:39 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0136.outbound.protection.outlook.com. [104.47.1.136]) by mx.google.com with ESMTPS id 1-v6si722577plw.164.2018.02.06.23.57.36 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 06 Feb 2018 23:57:37 -0800 (PST) Subject: Re: [PATCH 0/2] rcu: Transform kfree_rcu() into kvfree_rcu() References: <151791170164.5994.8253310844733420079.stgit@localhost.localdomain> <20180207021703.GC3617@linux.vnet.ibm.com> <20180207042334.GA16175@bombadil.infradead.org> <20180207050200.GH3617@linux.vnet.ibm.com> From: Kirill Tkhai Message-ID: Date: Wed, 7 Feb 2018 10:57:28 +0300 MIME-Version: 1.0 In-Reply-To: <20180207050200.GH3617@linux.vnet.ibm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: paulmck@linux.vnet.ibm.com, Matthew Wilcox Cc: josh@joshtriplett.org, rostedt@goodmis.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, brouer@redhat.com, rao.shoaib@oracle.com On 07.02.2018 08:02, Paul E. McKenney wrote: > On Tue, Feb 06, 2018 at 08:23:34PM -0800, Matthew Wilcox wrote: >> On Tue, Feb 06, 2018 at 06:17:03PM -0800, Paul E. McKenney wrote: >>> So it is OK to kvmalloc() something and pass it to either kfree() or >>> kvfree(), and it had better be OK to kvmalloc() something and pass it >>> to kvfree(). >>> >>> Is it OK to kmalloc() something and pass it to kvfree()? >> >> Yes, it absolutely is. >> >> void kvfree(const void *addr) >> { >> if (is_vmalloc_addr(addr)) >> vfree(addr); >> else >> kfree(addr); >> } >> >>> If so, is it really useful to have two different names here, that is, >>> both kfree_rcu() and kvfree_rcu()? >> >> I think it's handy to have all three of kvfree_rcu(), kfree_rcu() and >> vfree_rcu() available in the API for the symmetry of calling kmalloc() >> / kfree_rcu(). >> >> Personally, I would like us to rename kvfree() to just free(), and have >> malloc(x) be an alias to kvmalloc(x, GFP_KERNEL), but I haven't won that >> fight yet. > > But why not just have the existing kfree_rcu() API cover both kmalloc() > and kvmalloc()? Perhaps I am not in the right forums, but I am not hearing > anyone arguing that the RCU API has too few members. ;-) People, far from RCU internals, consider kfree_rcu() like an extension of kfree(). And it's not clear it's need to dive into kfree_rcu() comments, when someone is looking a primitive to free vmalloc'ed memory. Also, construction like obj = kvmalloc(); kfree_rcu(obj); makes me think it's legitimately to use plain kfree() as pair bracket to kvmalloc(). So the significant change of kfree_rcu() behavior will complicate stable backporters life, because they will need to keep in mind such differences between different kernel versions. It seems if we are going to use the single primitive for both kmalloc() and kvmalloc() memory, it has to have another name. But I don't see problems with having both kfree_rcu() and kvfree_rcu(). Kirill -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-f197.google.com (mail-qk0-f197.google.com [209.85.220.197]) by kanga.kvack.org (Postfix) with ESMTP id CB6246B02E4 for ; Wed, 7 Feb 2018 03:20:25 -0500 (EST) Received: by mail-qk0-f197.google.com with SMTP id c135so13332qkb.10 for ; Wed, 07 Feb 2018 00:20:25 -0800 (PST) Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com. [148.163.158.5]) by mx.google.com with ESMTPS id f47si992074qtc.420.2018.02.07.00.20.25 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Feb 2018 00:20:25 -0800 (PST) Received: from pps.filterd (m0098416.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w178JsjS011520 for ; Wed, 7 Feb 2018 03:20:24 -0500 Received: from e11.ny.us.ibm.com (e11.ny.us.ibm.com [129.33.205.201]) by mx0b-001b2d01.pphosted.com with ESMTP id 2fypywesvp-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Wed, 07 Feb 2018 03:20:24 -0500 Received: from localhost by e11.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 7 Feb 2018 03:20:23 -0500 Date: Wed, 7 Feb 2018 00:20:29 -0800 From: "Paul E. McKenney" Subject: Re: [PATCH 0/2] rcu: Transform kfree_rcu() into kvfree_rcu() Reply-To: paulmck@linux.vnet.ibm.com References: <151791170164.5994.8253310844733420079.stgit@localhost.localdomain> <20180207021703.GC3617@linux.vnet.ibm.com> <20180207042334.GA16175@bombadil.infradead.org> <20180207050200.GH3617@linux.vnet.ibm.com> <20180207075409.GA5726@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180207075409.GA5726@localhost> Message-Id: <20180207082029.GJ3617@linux.vnet.ibm.com> Sender: owner-linux-mm@kvack.org List-ID: To: Josh Triplett Cc: Matthew Wilcox , Kirill Tkhai , rostedt@goodmis.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, brouer@redhat.com, rao.shoaib@oracle.com On Tue, Feb 06, 2018 at 11:54:09PM -0800, Josh Triplett wrote: > On Tue, Feb 06, 2018 at 09:02:00PM -0800, Paul E. McKenney wrote: > > On Tue, Feb 06, 2018 at 08:23:34PM -0800, Matthew Wilcox wrote: > > > On Tue, Feb 06, 2018 at 06:17:03PM -0800, Paul E. McKenney wrote: > > > > So it is OK to kvmalloc() something and pass it to either kfree() or > > > > kvfree(), and it had better be OK to kvmalloc() something and pass it > > > > to kvfree(). > > > > > > > > Is it OK to kmalloc() something and pass it to kvfree()? > > > > > > Yes, it absolutely is. > > > > > > void kvfree(const void *addr) > > > { > > > if (is_vmalloc_addr(addr)) > > > vfree(addr); > > > else > > > kfree(addr); > > > } > > > > > > > If so, is it really useful to have two different names here, that is, > > > > both kfree_rcu() and kvfree_rcu()? > > > > > > I think it's handy to have all three of kvfree_rcu(), kfree_rcu() and > > > vfree_rcu() available in the API for the symmetry of calling kmalloc() > > > / kfree_rcu(). > > > > > > Personally, I would like us to rename kvfree() to just free(), and have > > > malloc(x) be an alias to kvmalloc(x, GFP_KERNEL), but I haven't won that > > > fight yet. > > > > But why not just have the existing kfree_rcu() API cover both kmalloc() > > and kvmalloc()? Perhaps I am not in the right forums, but I am not hearing > > anyone arguing that the RCU API has too few members. ;-) > > I don't have any problem with having just `kvfree_rcu`, but having just > `kfree_rcu` seems confusingly asymmetric. I don't understand why kmalloc()/kvfree_rcu() would seem any less asymmetric than kvmalloc()/kfree_rcu(). > (Also, count me in favor of having just one "free" function, too.) We agree on that much, anyway. ;-) 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt0-f197.google.com (mail-qt0-f197.google.com [209.85.216.197]) by kanga.kvack.org (Postfix) with ESMTP id 8C02F6B02E6 for ; Wed, 7 Feb 2018 03:31:02 -0500 (EST) Received: by mail-qt0-f197.google.com with SMTP id z13so35810qth.22 for ; Wed, 07 Feb 2018 00:31:02 -0800 (PST) Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com. [148.163.156.1]) by mx.google.com with ESMTPS id y127si965358qkd.306.2018.02.07.00.31.01 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Feb 2018 00:31:01 -0800 (PST) Received: from pps.filterd (m0098393.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w178UYVe089935 for ; Wed, 7 Feb 2018 03:31:00 -0500 Received: from e11.ny.us.ibm.com (e11.ny.us.ibm.com [129.33.205.201]) by mx0a-001b2d01.pphosted.com with ESMTP id 2fyws9rsgx-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Wed, 07 Feb 2018 03:31:00 -0500 Received: from localhost by e11.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 7 Feb 2018 03:30:58 -0500 Date: Wed, 7 Feb 2018 00:31:04 -0800 From: "Paul E. McKenney" Subject: Re: [PATCH 0/2] rcu: Transform kfree_rcu() into kvfree_rcu() Reply-To: paulmck@linux.vnet.ibm.com References: <151791170164.5994.8253310844733420079.stgit@localhost.localdomain> <20180207021703.GC3617@linux.vnet.ibm.com> <20180207042334.GA16175@bombadil.infradead.org> <20180207050200.GH3617@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Message-Id: <20180207083104.GK3617@linux.vnet.ibm.com> Sender: owner-linux-mm@kvack.org List-ID: To: Kirill Tkhai Cc: Matthew Wilcox , josh@joshtriplett.org, rostedt@goodmis.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, brouer@redhat.com, rao.shoaib@oracle.com On Wed, Feb 07, 2018 at 10:57:28AM +0300, Kirill Tkhai wrote: > On 07.02.2018 08:02, Paul E. McKenney wrote: > > On Tue, Feb 06, 2018 at 08:23:34PM -0800, Matthew Wilcox wrote: > >> On Tue, Feb 06, 2018 at 06:17:03PM -0800, Paul E. McKenney wrote: > >>> So it is OK to kvmalloc() something and pass it to either kfree() or > >>> kvfree(), and it had better be OK to kvmalloc() something and pass it > >>> to kvfree(). > >>> > >>> Is it OK to kmalloc() something and pass it to kvfree()? > >> > >> Yes, it absolutely is. > >> > >> void kvfree(const void *addr) > >> { > >> if (is_vmalloc_addr(addr)) > >> vfree(addr); > >> else > >> kfree(addr); > >> } > >> > >>> If so, is it really useful to have two different names here, that is, > >>> both kfree_rcu() and kvfree_rcu()? > >> > >> I think it's handy to have all three of kvfree_rcu(), kfree_rcu() and > >> vfree_rcu() available in the API for the symmetry of calling kmalloc() > >> / kfree_rcu(). > >> > >> Personally, I would like us to rename kvfree() to just free(), and have > >> malloc(x) be an alias to kvmalloc(x, GFP_KERNEL), but I haven't won that > >> fight yet. > > > > But why not just have the existing kfree_rcu() API cover both kmalloc() > > and kvmalloc()? Perhaps I am not in the right forums, but I am not hearing > > anyone arguing that the RCU API has too few members. ;-) > > People, far from RCU internals, consider kfree_rcu() like an extension > of kfree(). And it's not clear it's need to dive into kfree_rcu() comments, > when someone is looking a primitive to free vmalloc'ed memory. Seems like a relatively simple lesson to teach. > Also, construction like > > obj = kvmalloc(); > kfree_rcu(obj); > > makes me think it's legitimately to use plain kfree() as pair bracket to kvmalloc(). So it all works as is, then. > So the significant change of kfree_rcu() behavior will complicate stable backporters > life, because they will need to keep in mind such differences between different > kernel versions. If I understood your construction above, that significant change in kfree_rcu() behavior has already happened. > It seems if we are going to use the single primitive for both kmalloc() > and kvmalloc() memory, it has to have another name. But I don't see problems > with having both kfree_rcu() and kvfree_rcu(). 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. 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f197.google.com (mail-pf0-f197.google.com [209.85.192.197]) by kanga.kvack.org (Postfix) with ESMTP id 2DB7C6B0313 for ; Wed, 7 Feb 2018 08:57:05 -0500 (EST) Received: by mail-pf0-f197.google.com with SMTP id e1so443582pfi.10 for ; Wed, 07 Feb 2018 05:57:05 -0800 (PST) Received: from mail.kernel.org (mail.kernel.org. [198.145.29.99]) by mx.google.com with ESMTPS id v10si978455pgf.214.2018.02.07.05.57.03 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Feb 2018 05:57:03 -0800 (PST) Date: Wed, 7 Feb 2018 08:57:00 -0500 From: Steven Rostedt Subject: Re: [PATCH 0/2] rcu: Transform kfree_rcu() into kvfree_rcu() Message-ID: <20180207085700.393f90d0@gandalf.local.home> In-Reply-To: <20180207083104.GK3617@linux.vnet.ibm.com> References: <151791170164.5994.8253310844733420079.stgit@localhost.localdomain> <20180207021703.GC3617@linux.vnet.ibm.com> <20180207042334.GA16175@bombadil.infradead.org> <20180207050200.GH3617@linux.vnet.ibm.com> <20180207083104.GK3617@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: "Paul E. McKenney" Cc: Kirill Tkhai , Matthew Wilcox , 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, brouer@redhat.com, rao.shoaib@oracle.com On Wed, 7 Feb 2018 00:31:04 -0800 "Paul E. McKenney" 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. -- Steve -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-f199.google.com (mail-io0-f199.google.com [209.85.223.199]) by kanga.kvack.org (Postfix) with ESMTP id 6E8EF6B0319 for ; Wed, 7 Feb 2018 09:55:50 -0500 (EST) Received: by mail-io0-f199.google.com with SMTP id 102so1391104ior.2 for ; Wed, 07 Feb 2018 06:55:50 -0800 (PST) Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net. [2001:558:fe21:29:69:252:207:41]) by mx.google.com with ESMTPS id m3si1109774iob.136.2018.02.07.06.55.49 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Feb 2018 06:55:49 -0800 (PST) Date: Wed, 7 Feb 2018 08:55:47 -0600 (CST) From: Christopher Lameter Subject: Re: [PATCH 0/2] rcu: Transform kfree_rcu() into kvfree_rcu() In-Reply-To: <20180207021703.GC3617@linux.vnet.ibm.com> Message-ID: References: <151791170164.5994.8253310844733420079.stgit@localhost.localdomain> <20180207021703.GC3617@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: owner-linux-mm@kvack.org List-ID: To: "Paul E. McKenney" Cc: Kirill Tkhai , josh@joshtriplett.org, rostedt@goodmis.org, mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com, mingo@redhat.com, penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, brouer@redhat.com, rao.shoaib@oracle.com On Tue, 6 Feb 2018, Paul E. McKenney wrote: > So it is OK to kvmalloc() something and pass it to either kfree() or > kvfree(), and it had better be OK to kvmalloc() something and pass it > to kvfree(). kvfree() is fine but not kfree(). -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f198.google.com (mail-pf0-f198.google.com [209.85.192.198]) by kanga.kvack.org (Postfix) with ESMTP id 09D716B032F for ; Wed, 7 Feb 2018 11:19:01 -0500 (EST) Received: by mail-pf0-f198.google.com with SMTP id m65so620073pfm.14 for ; Wed, 07 Feb 2018 08:19:01 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org. [65.50.211.133]) by mx.google.com with ESMTPS id u13si1108589pgr.530.2018.02.07.08.18.59 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 07 Feb 2018 08:18:59 -0800 (PST) Date: Wed, 7 Feb 2018 08:18:46 -0800 From: Matthew Wilcox Subject: Re: [PATCH 0/2] rcu: Transform kfree_rcu() into kvfree_rcu() Message-ID: <20180207161846.GA902@bombadil.infradead.org> References: <151791170164.5994.8253310844733420079.stgit@localhost.localdomain> <20180207021703.GC3617@linux.vnet.ibm.com> <20180207042334.GA16175@bombadil.infradead.org> <20180207050200.GH3617@linux.vnet.ibm.com> <20180207083104.GK3617@linux.vnet.ibm.com> <20180207085700.393f90d0@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180207085700.393f90d0@gandalf.local.home> Sender: owner-linux-mm@kvack.org List-ID: To: Steven Rostedt Cc: "Paul E. McKenney" , Kirill Tkhai , 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, brouer@redhat.com, rao.shoaib@oracle.com On Wed, Feb 07, 2018 at 08:57:00AM -0500, Steven Rostedt wrote: > On Wed, 7 Feb 2018 00:31:04 -0800 > "Paul E. McKenney" 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 You missed kvmalloc() ... > 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. I'd still like it to be called free_rcu() ... so let's turn it around. What memory can you allocate and then *not* free by calling kvfree()? kvfree() can free memory allocated by kmalloc(), vmalloc(), any slab allocation (is that guaranteed, or just something that happens to work?) I think it can't free per-cpu allocations, bootmem, DMA allocations, or alloc_page/get_free_page. Do we need to be able to free any of those objects in order to rename kfree_rcu() to just free_rcu()? -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg0-f70.google.com (mail-pg0-f70.google.com [74.125.83.70]) by kanga.kvack.org (Postfix) with ESMTP id C47496B0335 for ; Wed, 7 Feb 2018 11:34:20 -0500 (EST) Received: by mail-pg0-f70.google.com with SMTP id b4so511152pgs.5 for ; Wed, 07 Feb 2018 08:34:20 -0800 (PST) Received: from mail.kernel.org (mail.kernel.org. [198.145.29.99]) by mx.google.com with ESMTPS id q11si1135605pgc.165.2018.02.07.08.34.19 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Feb 2018 08:34:19 -0800 (PST) Date: Wed, 7 Feb 2018 11:34:16 -0500 From: Steven Rostedt Subject: Re: [PATCH 0/2] rcu: Transform kfree_rcu() into kvfree_rcu() Message-ID: <20180207113416.33b6247b@gandalf.local.home> In-Reply-To: <20180207161846.GA902@bombadil.infradead.org> References: <151791170164.5994.8253310844733420079.stgit@localhost.localdomain> <20180207021703.GC3617@linux.vnet.ibm.com> <20180207042334.GA16175@bombadil.infradead.org> <20180207050200.GH3617@linux.vnet.ibm.com> <20180207083104.GK3617@linux.vnet.ibm.com> <20180207085700.393f90d0@gandalf.local.home> <20180207161846.GA902@bombadil.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Matthew Wilcox Cc: "Paul E. McKenney" , Kirill Tkhai , 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, brouer@redhat.com, rao.shoaib@oracle.com On Wed, 7 Feb 2018 08:18:46 -0800 Matthew Wilcox wrote: > Do we need to be able to free any of those objects in order to rename > kfree_rcu() to just free_rcu()? I'm just nervous about tightly coupling free_rcu() with all the *free() from the memory management system. I've been burnt in the past by doing such things. What's the down side of having a way of matching *free_rcu() with all the *free()s? I think it's easier to understand, and rcu doesn't need to worry about changes of *free() code. To me: kfree_rcu(x); is just a quick way of doing 'kfree(x)' after a synchronize_rcu() call. But a "free_rcu(x)", is something I have to think about, because I don't know from the name exactly what it is doing. I know this may sound a bit bike shedding, but the less I need to think about how other sub systems work, the easier it is to concentrate on my own sub system. -- Steve -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-f198.google.com (mail-qk0-f198.google.com [209.85.220.198]) by kanga.kvack.org (Postfix) with ESMTP id 704EB6B0337 for ; Wed, 7 Feb 2018 11:45:24 -0500 (EST) Received: by mail-qk0-f198.google.com with SMTP id w74so1395926qka.21 for ; Wed, 07 Feb 2018 08:45:24 -0800 (PST) Received: from mx1.redhat.com (mx3-rdu2.redhat.com. [66.187.233.73]) by mx.google.com with ESMTPS id 23si1953563qtr.35.2018.02.07.08.45.23 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Feb 2018 08:45:23 -0800 (PST) Date: Wed, 7 Feb 2018 17:45:13 +0100 From: Jesper Dangaard Brouer Subject: Re: [PATCH 0/2] rcu: Transform kfree_rcu() into kvfree_rcu() Message-ID: <20180207174513.5cc9b503@redhat.com> In-Reply-To: <20180207085700.393f90d0@gandalf.local.home> References: <151791170164.5994.8253310844733420079.stgit@localhost.localdomain> <20180207021703.GC3617@linux.vnet.ibm.com> <20180207042334.GA16175@bombadil.infradead.org> <20180207050200.GH3617@linux.vnet.ibm.com> <20180207083104.GK3617@linux.vnet.ibm.com> <20180207085700.393f90d0@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Steven Rostedt Cc: "Paul E. McKenney" , Kirill Tkhai , Matthew Wilcox , 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 On Wed, 7 Feb 2018 08:57:00 -0500 Steven Rostedt wrote: > On Wed, 7 Feb 2018 00:31:04 -0800 > "Paul E. McKenney" 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-f198.google.com (mail-io0-f198.google.com [209.85.223.198]) by kanga.kvack.org (Postfix) with ESMTP id DE8EF6B0339 for ; Wed, 7 Feb 2018 11:47:06 -0500 (EST) Received: by mail-io0-f198.google.com with SMTP id d62so1633606iof.8 for ; Wed, 07 Feb 2018 08:47:06 -0800 (PST) Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net. [2001:558:fe21:29:69:252:207:41]) by mx.google.com with ESMTPS id r142si199309itr.18.2018.02.07.08.47.05 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Feb 2018 08:47:06 -0800 (PST) Date: Wed, 7 Feb 2018 10:47:02 -0600 (CST) From: Christopher Lameter Subject: Re: [PATCH 0/2] rcu: Transform kfree_rcu() into kvfree_rcu() In-Reply-To: <20180207042334.GA16175@bombadil.infradead.org> Message-ID: References: <151791170164.5994.8253310844733420079.stgit@localhost.localdomain> <20180207021703.GC3617@linux.vnet.ibm.com> <20180207042334.GA16175@bombadil.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: owner-linux-mm@kvack.org List-ID: To: Matthew Wilcox Cc: "Paul E. McKenney" , Kirill Tkhai , josh@joshtriplett.org, rostedt@goodmis.org, mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com, mingo@redhat.com, penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, brouer@redhat.com, rao.shoaib@oracle.com On Tue, 6 Feb 2018, Matthew Wilcox wrote: > Personally, I would like us to rename kvfree() to just free(), and have > malloc(x) be an alias to kvmalloc(x, GFP_KERNEL), but I haven't won that > fight yet. Maybe lets implement malloc(), free() and realloc() in the kernel to be consistent with user space use as possible? Only use the others allocation variants for special cases. So malloc would check allocation sizes and if < 2* PAGE_SIZE use kmalloc() otherwise vmalloc(). free() would free anything you give it. -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f198.google.com (mail-pf0-f198.google.com [209.85.192.198]) by kanga.kvack.org (Postfix) with ESMTP id CDE0A6B0344 for ; Wed, 7 Feb 2018 12:09:53 -0500 (EST) Received: by mail-pf0-f198.google.com with SMTP id a9so702720pff.0 for ; Wed, 07 Feb 2018 09:09:53 -0800 (PST) Received: from mail.kernel.org (mail.kernel.org. [198.145.29.99]) by mx.google.com with ESMTPS id 28si1394377pfl.53.2018.02.07.09.09.52 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Feb 2018 09:09:52 -0800 (PST) Date: Wed, 7 Feb 2018 12:09:49 -0500 From: Steven Rostedt Subject: Re: [PATCH 0/2] rcu: Transform kfree_rcu() into kvfree_rcu() Message-ID: <20180207120949.62fa815f@gandalf.local.home> In-Reply-To: References: <151791170164.5994.8253310844733420079.stgit@localhost.localdomain> <20180207021703.GC3617@linux.vnet.ibm.com> <20180207042334.GA16175@bombadil.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Christopher Lameter Cc: Matthew Wilcox , "Paul E. McKenney" , Kirill Tkhai , josh@joshtriplett.org, mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com, mingo@redhat.com, penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, brouer@redhat.com, rao.shoaib@oracle.com On Wed, 7 Feb 2018 10:47:02 -0600 (CST) Christopher Lameter wrote: > On Tue, 6 Feb 2018, Matthew Wilcox wrote: > > > Personally, I would like us to rename kvfree() to just free(), and have > > malloc(x) be an alias to kvmalloc(x, GFP_KERNEL), but I haven't won that > > fight yet. > > Maybe lets implement malloc(), free() and realloc() in the kernel to be > consistent with user space use as possible? Only use the others > allocation variants for special cases. They would need to drop the GFP part and default to GFP_KERNEL. > > So malloc would check allocation sizes and if < 2* PAGE_SIZE use kmalloc() > otherwise vmalloc(). Please no, I hate subtle internal decisions like this. It makes debugging much more difficult, when allocating dynamic sized variables. When something works at one size but not the other. -- Steve > > free() would free anything you give it. -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl0-f72.google.com (mail-pl0-f72.google.com [209.85.160.72]) by kanga.kvack.org (Postfix) with ESMTP id 44DC26B0349 for ; Wed, 7 Feb 2018 12:19:59 -0500 (EST) Received: by mail-pl0-f72.google.com with SMTP id h33-v6so261417plh.19 for ; Wed, 07 Feb 2018 09:19:59 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org. [65.50.211.133]) by mx.google.com with ESMTPS id l193si1183791pge.274.2018.02.07.09.19.58 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 07 Feb 2018 09:19:58 -0800 (PST) Date: Wed, 7 Feb 2018 09:19:36 -0800 From: Matthew Wilcox Subject: Re: [PATCH 0/2] rcu: Transform kfree_rcu() into kvfree_rcu() Message-ID: <20180207171936.GA12446@bombadil.infradead.org> References: <151791170164.5994.8253310844733420079.stgit@localhost.localdomain> <20180207021703.GC3617@linux.vnet.ibm.com> <20180207042334.GA16175@bombadil.infradead.org> <20180207120949.62fa815f@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180207120949.62fa815f@gandalf.local.home> Sender: owner-linux-mm@kvack.org List-ID: To: Steven Rostedt Cc: Christopher Lameter , "Paul E. McKenney" , Kirill Tkhai , josh@joshtriplett.org, mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com, mingo@redhat.com, penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, brouer@redhat.com, rao.shoaib@oracle.com On Wed, Feb 07, 2018 at 12:09:49PM -0500, Steven Rostedt wrote: > > Maybe lets implement malloc(), free() and realloc() in the kernel to be > > consistent with user space use as possible? Only use the others > > allocation variants for special cases. > > They would need to drop the GFP part and default to GFP_KERNEL. Yes, exactly. > > So malloc would check allocation sizes and if < 2* PAGE_SIZE use kmalloc() > > otherwise vmalloc(). > > Please no, I hate subtle internal decisions like this. It makes > debugging much more difficult, when allocating dynamic sized variables. > When something works at one size but not the other. You know we already have kvmalloc()? -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg0-f69.google.com (mail-pg0-f69.google.com [74.125.83.69]) by kanga.kvack.org (Postfix) with ESMTP id 7A9BB6B034D for ; Wed, 7 Feb 2018 12:29:15 -0500 (EST) Received: by mail-pg0-f69.google.com with SMTP id q2so550451pgf.22 for ; Wed, 07 Feb 2018 09:29:15 -0800 (PST) Received: from mail.kernel.org (mail.kernel.org. [198.145.29.99]) by mx.google.com with ESMTPS id l61-v6si1383713plb.219.2018.02.07.09.29.14 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Feb 2018 09:29:14 -0800 (PST) Date: Wed, 7 Feb 2018 12:29:10 -0500 From: Steven Rostedt Subject: Re: [PATCH 0/2] rcu: Transform kfree_rcu() into kvfree_rcu() Message-ID: <20180207122910.1a91a48e@gandalf.local.home> In-Reply-To: <20180207171936.GA12446@bombadil.infradead.org> References: <151791170164.5994.8253310844733420079.stgit@localhost.localdomain> <20180207021703.GC3617@linux.vnet.ibm.com> <20180207042334.GA16175@bombadil.infradead.org> <20180207120949.62fa815f@gandalf.local.home> <20180207171936.GA12446@bombadil.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Matthew Wilcox Cc: Christopher Lameter , "Paul E. McKenney" , Kirill Tkhai , josh@joshtriplett.org, mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com, mingo@redhat.com, penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, brouer@redhat.com, rao.shoaib@oracle.com On Wed, 7 Feb 2018 09:19:36 -0800 Matthew Wilcox wrote: > > Please no, I hate subtle internal decisions like this. It makes > > debugging much more difficult, when allocating dynamic sized variables. > > When something works at one size but not the other. > > You know we already have kvmalloc()? Yes, and the name suggests exactly what it does. It has both "k" and "v" which tells me that if I use it it could be one or the other. But a generic "malloc" or "free" that does things differently depending on the size is a different story. -- Steve -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-f70.google.com (mail-it0-f70.google.com [209.85.214.70]) by kanga.kvack.org (Postfix) with ESMTP id 5A58E6B0355 for ; Wed, 7 Feb 2018 12:54:26 -0500 (EST) Received: by mail-it0-f70.google.com with SMTP id i135so2425228ita.9 for ; Wed, 07 Feb 2018 09:54:26 -0800 (PST) Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net. [2001:558:fe21:29:69:252:207:44]) by mx.google.com with ESMTPS id b186si129296ith.72.2018.02.07.09.54.25 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Feb 2018 09:54:25 -0800 (PST) Date: Wed, 7 Feb 2018 11:54:22 -0600 (CST) From: Christopher Lameter Subject: Re: [PATCH 0/2] rcu: Transform kfree_rcu() into kvfree_rcu() In-Reply-To: <20180207122910.1a91a48e@gandalf.local.home> Message-ID: References: <151791170164.5994.8253310844733420079.stgit@localhost.localdomain> <20180207021703.GC3617@linux.vnet.ibm.com> <20180207042334.GA16175@bombadil.infradead.org> <20180207120949.62fa815f@gandalf.local.home> <20180207171936.GA12446@bombadil.infradead.org> <20180207122910.1a91a48e@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: owner-linux-mm@kvack.org List-ID: To: Steven Rostedt Cc: Matthew Wilcox , "Paul E. McKenney" , Kirill Tkhai , josh@joshtriplett.org, mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com, mingo@redhat.com, penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, brouer@redhat.com, rao.shoaib@oracle.com On Wed, 7 Feb 2018, Steven Rostedt wrote: > But a generic "malloc" or "free" that does things differently depending > on the size is a different story. They would not be used for cases with special requirements but for the throwaway allows where noone cares about these details. Its just a convenience for the developers that do not need to be bothered with too much detail because they are not dealing with codepaths that have special requirements. -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg0-f71.google.com (mail-pg0-f71.google.com [74.125.83.71]) by kanga.kvack.org (Postfix) with ESMTP id 82A5E6B0356 for ; Wed, 7 Feb 2018 13:11:09 -0500 (EST) Received: by mail-pg0-f71.google.com with SMTP id r1so612065pgp.2 for ; Wed, 07 Feb 2018 10:11:09 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org. [65.50.211.133]) by mx.google.com with ESMTPS id v19-v6si1430899ply.494.2018.02.07.10.11.08 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 07 Feb 2018 10:11:08 -0800 (PST) Date: Wed, 7 Feb 2018 10:10:55 -0800 From: Matthew Wilcox Subject: Re: [PATCH 0/2] rcu: Transform kfree_rcu() into kvfree_rcu() Message-ID: <20180207181055.GB12446@bombadil.infradead.org> References: <151791170164.5994.8253310844733420079.stgit@localhost.localdomain> <20180207021703.GC3617@linux.vnet.ibm.com> <20180207042334.GA16175@bombadil.infradead.org> <20180207050200.GH3617@linux.vnet.ibm.com> <20180207083104.GK3617@linux.vnet.ibm.com> <20180207085700.393f90d0@gandalf.local.home> <20180207174513.5cc9b503@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180207174513.5cc9b503@redhat.com> Sender: owner-linux-mm@kvack.org List-ID: To: Jesper Dangaard Brouer Cc: Steven Rostedt , "Paul E. McKenney" , Kirill Tkhai , 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 On Wed, Feb 07, 2018 at 05:45:13PM +0100, Jesper Dangaard Brouer wrote: > On Wed, 7 Feb 2018 08:57:00 -0500 > Steven Rostedt wrote: > > 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" ;-)) While free_rcu() is not withut its performance requirements, I think it's currently dominated by cache misses and not by branches. By the time RCU gets to run callbacks, memory is certainly L1/L2 cache-cold and probably L3 cache-cold. Also calling the callback functions is utterly impossible for the branch predictor. -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg0-f69.google.com (mail-pg0-f69.google.com [74.125.83.69]) by kanga.kvack.org (Postfix) with ESMTP id BBA7E6B0359 for ; Wed, 7 Feb 2018 13:26:23 -0500 (EST) Received: by mail-pg0-f69.google.com with SMTP id w19so622713pgv.4 for ; Wed, 07 Feb 2018 10:26:23 -0800 (PST) Received: from mail.kernel.org (mail.kernel.org. [198.145.29.99]) by mx.google.com with ESMTPS id u145si1253021pgb.358.2018.02.07.10.26.22 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Feb 2018 10:26:22 -0800 (PST) Date: Wed, 7 Feb 2018 13:26:19 -0500 From: Steven Rostedt Subject: Re: [PATCH 0/2] rcu: Transform kfree_rcu() into kvfree_rcu() Message-ID: <20180207132619.6595e4a9@gandalf.local.home> In-Reply-To: <20180207181055.GB12446@bombadil.infradead.org> References: <151791170164.5994.8253310844733420079.stgit@localhost.localdomain> <20180207021703.GC3617@linux.vnet.ibm.com> <20180207042334.GA16175@bombadil.infradead.org> <20180207050200.GH3617@linux.vnet.ibm.com> <20180207083104.GK3617@linux.vnet.ibm.com> <20180207085700.393f90d0@gandalf.local.home> <20180207174513.5cc9b503@redhat.com> <20180207181055.GB12446@bombadil.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Matthew Wilcox Cc: Jesper Dangaard Brouer , "Paul E. McKenney" , Kirill Tkhai , 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 On Wed, 7 Feb 2018 10:10:55 -0800 Matthew Wilcox wrote: > > For the record, I fully agree with Steve here. Thanks, but... > > > > 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" ;-)) > > While free_rcu() is not withut its performance requirements, I think it's > currently dominated by cache misses and not by branches. By the time RCU > gets to run callbacks, memory is certainly L1/L2 cache-cold and probably > L3 cache-cold. Also calling the callback functions is utterly impossible > for the branch predictor. I agree with Matthew. This is far from any fast path. A few extra branches isn't going to hurt anything here as it's mostly just garbage collection. With or without the Spectre fixes. -- Steve -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt0-f200.google.com (mail-qt0-f200.google.com [209.85.216.200]) by kanga.kvack.org (Postfix) with ESMTP id A52526B0006 for ; Wed, 7 Feb 2018 23:09:05 -0500 (EST) Received: by mail-qt0-f200.google.com with SMTP id d15so2795139qtg.2 for ; Wed, 07 Feb 2018 20:09:05 -0800 (PST) Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com. [148.163.158.5]) by mx.google.com with ESMTPS id 28si1906883qtq.280.2018.02.07.20.09.04 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Feb 2018 20:09:04 -0800 (PST) Received: from pps.filterd (m0098419.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w18440Du103537 for ; Wed, 7 Feb 2018 23:09:04 -0500 Received: from e19.ny.us.ibm.com (e19.ny.us.ibm.com [129.33.205.209]) by mx0b-001b2d01.pphosted.com with ESMTP id 2g0ab69uw5-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Wed, 07 Feb 2018 23:09:04 -0500 Received: from localhost by e19.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 7 Feb 2018 23:09:03 -0500 Date: Wed, 7 Feb 2018 20:09:10 -0800 From: "Paul E. McKenney" Subject: Re: [PATCH 0/2] rcu: Transform kfree_rcu() into kvfree_rcu() Reply-To: paulmck@linux.vnet.ibm.com References: <151791170164.5994.8253310844733420079.stgit@localhost.localdomain> <20180207021703.GC3617@linux.vnet.ibm.com> <20180207042334.GA16175@bombadil.infradead.org> <20180207050200.GH3617@linux.vnet.ibm.com> <20180207083104.GK3617@linux.vnet.ibm.com> <20180207085700.393f90d0@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180207085700.393f90d0@gandalf.local.home> Message-Id: <20180208040910.GP3617@linux.vnet.ibm.com> Sender: owner-linux-mm@kvack.org List-ID: To: Steven Rostedt Cc: Kirill Tkhai , Matthew Wilcox , 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, brouer@redhat.com, rao.shoaib@oracle.com On Wed, Feb 07, 2018 at 08:57:00AM -0500, Steven Rostedt wrote: > On Wed, 7 Feb 2018 00:31:04 -0800 > "Paul E. McKenney" 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. I couldn't agree more! To that end, what are your thoughts on this patch? https://lkml.kernel.org/r/1513895570-28640-1-git-send-email-rao.shoaib@oracle.com Advantages include the ability to optimize based on sl[aou]b state, getting rid of the 4K offset hack in __is_kfree_rcu_offset(), better cache localite, and, as you say, putting the naming responsibility in the memory-management domain. > 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. And that is one reason I am viewing the name-change patch with great suspicion, especially given that there seems to be some controversy among the memory-management folks as to exactly what the names should be. 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-f197.google.com (mail-qk0-f197.google.com [209.85.220.197]) by kanga.kvack.org (Postfix) with ESMTP id 1CA0D6B0009 for ; Wed, 7 Feb 2018 23:09:27 -0500 (EST) Received: by mail-qk0-f197.google.com with SMTP id q185so2769091qke.2 for ; Wed, 07 Feb 2018 20:09:27 -0800 (PST) Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com. [148.163.156.1]) by mx.google.com with ESMTPS id y54si872373qth.38.2018.02.07.20.09.26 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Feb 2018 20:09:26 -0800 (PST) Received: from pps.filterd (m0098394.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1849LFP022143 for ; Wed, 7 Feb 2018 23:09:25 -0500 Received: from e13.ny.us.ibm.com (e13.ny.us.ibm.com [129.33.205.203]) by mx0a-001b2d01.pphosted.com with ESMTP id 2g0dm3u5da-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Wed, 07 Feb 2018 23:09:25 -0500 Received: from localhost by e13.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 7 Feb 2018 23:09:24 -0500 Date: Wed, 7 Feb 2018 20:09:29 -0800 From: "Paul E. McKenney" Subject: Re: [PATCH 0/2] rcu: Transform kfree_rcu() into kvfree_rcu() Reply-To: paulmck@linux.vnet.ibm.com References: <151791170164.5994.8253310844733420079.stgit@localhost.localdomain> <20180207021703.GC3617@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Message-Id: <20180208040929.GQ3617@linux.vnet.ibm.com> Sender: owner-linux-mm@kvack.org List-ID: To: Christopher Lameter Cc: Kirill Tkhai , josh@joshtriplett.org, rostedt@goodmis.org, mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com, mingo@redhat.com, penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, brouer@redhat.com, rao.shoaib@oracle.com On Wed, Feb 07, 2018 at 08:55:47AM -0600, Christopher Lameter wrote: > On Tue, 6 Feb 2018, Paul E. McKenney wrote: > > > So it is OK to kvmalloc() something and pass it to either kfree() or > > kvfree(), and it had better be OK to kvmalloc() something and pass it > > to kvfree(). > > kvfree() is fine but not kfree(). Ah, even more fun, then! ;-) 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-f197.google.com (mail-qk0-f197.google.com [209.85.220.197]) by kanga.kvack.org (Postfix) with ESMTP id 86CF46B000C for ; Wed, 7 Feb 2018 23:10:35 -0500 (EST) Received: by mail-qk0-f197.google.com with SMTP id z64so2713060qka.23 for ; Wed, 07 Feb 2018 20:10:35 -0800 (PST) Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com. [148.163.158.5]) by mx.google.com with ESMTPS id y187si502684qkc.309.2018.02.07.20.10.34 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Feb 2018 20:10:34 -0800 (PST) Received: from pps.filterd (m0098417.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1849S1F096797 for ; Wed, 7 Feb 2018 23:10:34 -0500 Received: from e19.ny.us.ibm.com (e19.ny.us.ibm.com [129.33.205.209]) by mx0a-001b2d01.pphosted.com with ESMTP id 2g09d93vxh-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Wed, 07 Feb 2018 23:10:34 -0500 Received: from localhost by e19.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 7 Feb 2018 23:10:33 -0500 Date: Wed, 7 Feb 2018 20:10:39 -0800 From: "Paul E. McKenney" Subject: Re: [PATCH 0/2] rcu: Transform kfree_rcu() into kvfree_rcu() Reply-To: paulmck@linux.vnet.ibm.com References: <151791170164.5994.8253310844733420079.stgit@localhost.localdomain> <20180207021703.GC3617@linux.vnet.ibm.com> <20180207042334.GA16175@bombadil.infradead.org> <20180207050200.GH3617@linux.vnet.ibm.com> <20180207083104.GK3617@linux.vnet.ibm.com> <20180207085700.393f90d0@gandalf.local.home> <20180207174513.5cc9b503@redhat.com> <20180207181055.GB12446@bombadil.infradead.org> <20180207132619.6595e4a9@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180207132619.6595e4a9@gandalf.local.home> Message-Id: <20180208041039.GR3617@linux.vnet.ibm.com> Sender: owner-linux-mm@kvack.org List-ID: To: Steven Rostedt Cc: Matthew Wilcox , Jesper Dangaard Brouer , Kirill Tkhai , 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 On Wed, Feb 07, 2018 at 01:26:19PM -0500, Steven Rostedt wrote: > On Wed, 7 Feb 2018 10:10:55 -0800 > Matthew Wilcox wrote: > > > > For the record, I fully agree with Steve here. > > Thanks, but... > > > > > > > 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" ;-)) > > > > While free_rcu() is not withut its performance requirements, I think it's > > currently dominated by cache misses and not by branches. By the time RCU > > gets to run callbacks, memory is certainly L1/L2 cache-cold and probably > > L3 cache-cold. Also calling the callback functions is utterly impossible > > for the branch predictor. > > I agree with Matthew. > > This is far from any fast path. A few extra branches isn't going to > hurt anything here as it's mostly just garbage collection. With or > without the Spectre fixes. What Steve said! 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt0-f197.google.com (mail-qt0-f197.google.com [209.85.216.197]) by kanga.kvack.org (Postfix) with ESMTP id 98F336B0003 for ; Thu, 22 Feb 2018 18:55:17 -0500 (EST) Received: by mail-qt0-f197.google.com with SMTP id d26so5337235qtm.14 for ; Thu, 22 Feb 2018 15:55:17 -0800 (PST) Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com. [148.163.156.1]) by mx.google.com with ESMTPS id d26si1191171qtf.17.2018.02.22.15.55.15 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Feb 2018 15:55:16 -0800 (PST) Received: from pps.filterd (m0098404.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1MNrbHv086223 for ; Thu, 22 Feb 2018 18:55:15 -0500 Received: from e19.ny.us.ibm.com (e19.ny.us.ibm.com [129.33.205.209]) by mx0a-001b2d01.pphosted.com with ESMTP id 2ga31wajnc-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Thu, 22 Feb 2018 18:55:14 -0500 Received: from localhost by e19.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 22 Feb 2018 18:55:13 -0500 Date: Thu, 22 Feb 2018 15:55:32 -0800 From: "Paul E. McKenney" Subject: Re: [PATCH 0/2] rcu: Transform kfree_rcu() into kvfree_rcu() Reply-To: paulmck@linux.vnet.ibm.com References: <151791170164.5994.8253310844733420079.stgit@localhost.localdomain> <20180207021703.GC3617@linux.vnet.ibm.com> <20180207042334.GA16175@bombadil.infradead.org> <20180207050200.GH3617@linux.vnet.ibm.com> <20180207083104.GK3617@linux.vnet.ibm.com> <20180207085700.393f90d0@gandalf.local.home> <20180207174513.5cc9b503@redhat.com> <20180207181055.GB12446@bombadil.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180207181055.GB12446@bombadil.infradead.org> Message-Id: <20180222235532.GA11181@linux.vnet.ibm.com> Sender: owner-linux-mm@kvack.org List-ID: To: Matthew Wilcox Cc: Jesper Dangaard Brouer , Steven Rostedt , Kirill Tkhai , 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 On Wed, Feb 07, 2018 at 10:10:55AM -0800, Matthew Wilcox wrote: > On Wed, Feb 07, 2018 at 05:45:13PM +0100, Jesper Dangaard Brouer wrote: > > On Wed, 7 Feb 2018 08:57:00 -0500 > > Steven Rostedt wrote: > > > 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" ;-)) > > While free_rcu() is not withut its performance requirements, I think it's > currently dominated by cache misses and not by branches. By the time RCU > gets to run callbacks, memory is certainly L1/L2 cache-cold and probably > L3 cache-cold. Also calling the callback functions is utterly impossible > for the branch predictor. This seems to have fallen by the wayside. To get things going again, I suggest starting out by simply replacing the kfree() in __rcu_reclaim() with kvfree(). If desired, a kvfree_rcu() can also be defined as a synonym for kfree_rcu(). This gets us a very simple and small patch which provides the ability to dispose of kvmalloc() memory after a grace period. 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752678AbeBFKTy (ORCPT ); Tue, 6 Feb 2018 05:19:54 -0500 Received: from mail-he1eur01on0136.outbound.protection.outlook.com ([104.47.0.136]:26688 "EHLO EUR01-HE1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752356AbeBFKTp (ORCPT ); Tue, 6 Feb 2018 05:19:45 -0500 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ktkhai@virtuozzo.com; Subject: [PATCH 0/2] rcu: Transform kfree_rcu() into kvfree_rcu() From: Kirill Tkhai To: paulmck@linux.vnet.ibm.com, josh@joshtriplett.org, rostedt@goodmis.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, ktkhai@virtuozzo.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org Date: Tue, 06 Feb 2018 13:19:29 +0300 Message-ID: <151791170164.5994.8253310844733420079.stgit@localhost.localdomain> User-Agent: StGit/0.18 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [195.214.232.6] X-ClientProxiedBy: HE1P190CA0031.EURP190.PROD.OUTLOOK.COM (2603:10a6:7:52::20) To AM5PR0801MB1331.eurprd08.prod.outlook.com (2603:10a6:203:1f::9) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 12138cbb-4122-4ab2-ea3e-08d56d4b1e76 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(7020095)(4652020)(4534165)(7168020)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603307)(7153060)(7193020);SRVR:AM5PR0801MB1331; X-Microsoft-Exchange-Diagnostics: 1;AM5PR0801MB1331;3:M+vD3dQ6w3ZtKYljwRx6mcnRJGKPEv8M+8VRaohkNbJgB1DYqOp3YkXWwj8qqPHiCpMf6MW9Hpot4XjJYZv/uQs8UBr9DMWLCGrI0bFYdfwnh7tIWP+FRB/nw6fr2RupZtEKThOlR+2POJU6vJPklYYKiP55xOj981Ya8xfpUMpSMjiUpOr4i4XKjnCI0MO6WoTApLq69qpKfxgMKoIpf0lnw5CIBcOob9yyI+UU3yQMu3VkKUSH6sKZvB1s/hoP;25:vkaaCUVquP85nAznu1UfvIF3w4DoA9gGloFXWZ0dtoU9TgtwmdMN7YHBQQ0wSPkIeRzs1dQrR5Vux/XxKjVLAyvxANCBAT9iOVGULtzovQMfWI3n2HKq7o+1c7YlA2aqKN9c+xl6ny6rILMiH/6aitFfbtJv2nOE10IM3qy2w+IIy2J/n/gMztej2G9Hu0Y37Sr/o2cqjT25hWZAl+W+uP3U4thhMvME7hLQihhts3tTo8AeXkkgMasQ2nCzKQlFE5RFf2kVsR4wpw8zeOcTJ9N5cl+m0XRrH1i2O/K0S2lUo28ODG5oGPUE8I3v1ASeUWGluiSAfOEWGdzCCNT+yg==;31:PW5ww+13CvMHK1/fTrvc5q2sge5SNoYOOOI84T5Sn14mhrYqkJk6HSnXr6HCQPqx0ngHVrCcmAJ1k1yZO0vOIqlKj82W4nP4fsyETRoG76WSMoGVBVqHHGPVkCDxYJf9PKMntx9yELg8+cLNpzoctD2Z/5uwPpzOZvigTcHgQtpaV6O+8DF4o6OCIblifwT6O7TQoAm9FNUlrTTfOpbGBGV3zgFBTydAqe/qjva3js4= X-MS-TrafficTypeDiagnostic: AM5PR0801MB1331: X-Microsoft-Exchange-Diagnostics: 1;AM5PR0801MB1331;20:jjCGwnszoMha/2gbKKLVp6bpaazbF3YrHXkeGcLkVyO/HBfiWE6q/1QnUT9Mlv+LRUGBHt/XqfFPt0NyCuut6uOaiS11gIoEqC6bMRg5f8usiurf8vkSy/5bEDrcNCkmQVJHmSfD1ft8Hl50yuElFr9cJaIuAm4rvEZYjV9B+YBLea0c5XmueLRrXlj9QTQePaHZXbf8xtm4KMvn31rcEtz6v7RAXQnz3kZqx45RVTY3n0wGMbMmXHvMu8NduuInYVZ/NfLyRFkUl6IyGGlNF/bM222nmg/Dg6o4a2yJfqIt81yMGQVXDkdPMH20EQIt/M8yAMHHiOfOO7Qwe69/JFvdmk+rXWtmhSgq2LJHf0RNPFnvNWE0duyacHp0Vy1ce7i32pZSSl5U5TggPB6KZ/ull/lYICijkIC3hH/SVd8=;4:IGO3FECW2Ef3sr4Q4zr8eLwg23QDp6LalB7zy7qIOrJ0rf9SzXX6BchGPfeY1DW4Yir328L9QxEcLxrMSUuINTCQUn7CIvMKMszLs7LUSEf1xiTlCn4E0EgG6LGUAEeHWMdRNgu0/UlA7vo5emMsegxphgHiSY6JGmxCdRH1HhgLYs8cQlpg6oglMGNbN32EnKL5+wns4LUABqHSpN1U+eEFNfcef/kzVk/NS1UycVC/W0vdd+umKkQW+Xf+GKFQqEHo1H8inEpH/fdED/xTPg== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040501)(2401047)(8121501046)(5005006)(3231101)(2400082)(944501161)(3002001)(10201501046)(93006095)(93001095)(6041288)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(20161123564045)(6072148)(201708071742011);SRVR:AM5PR0801MB1331;BCL:0;PCL:0;RULEID:;SRVR:AM5PR0801MB1331; X-Forefront-PRVS: 0575F81B58 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(6069001)(376002)(396003)(366004)(346002)(39840400004)(39380400002)(189003)(199004)(9686003)(8676002)(3846002)(58126008)(53936002)(59450400001)(33896004)(478600001)(103116003)(186003)(105586002)(55236004)(7416002)(6506007)(26005)(16526019)(386003)(6116002)(106356001)(55016002)(230700001)(61506002)(305945005)(316002)(68736007)(7736002)(86362001)(2486003)(7696005)(47776003)(81156014)(50466002)(23676004)(52116002)(8936002)(6666003)(81166006)(97736004)(39060400002)(5660300001)(25786009)(66066001)(83506002)(2906002)(921003)(1121003);DIR:OUT;SFP:1102;SCL:1;SRVR:AM5PR0801MB1331;H:localhost.localdomain;FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTTVQUjA4MDFNQjEzMzE7MjM6SGN5QU16MmRPRklSeDh6NTRFeXFvSkhY?= =?utf-8?B?Y0djZjZKaTlyTmFWeGY3bkdnMWNYTU8xQWFONTVFbFJMNEQrN3h0MXM5RFBs?= =?utf-8?B?aElFZHNMK2dzYU9wVy9ka3B6ek1MTjlUNTV2eVZoemxYVHBDMGovbmxNdk5C?= =?utf-8?B?dEdvUnBPMHRNVHhIQldaOHdLcThJRWoxS2hYUDVQTitZWXVFOWVpVm5lT1lP?= =?utf-8?B?R2s2a1BZTzRBZGxIN1JGcGJpUzBQTGtoVEZXSkZHSVpDU0tLV2J4Q1FlWTJZ?= =?utf-8?B?RTJTWW1vSzdibDQ3MzIzM0lLZ1d6ZEhzenAwVXpTdVNTdDdlYjJqS0pFdDNS?= =?utf-8?B?QklVYWN2dGpiZHJXQmVMai9Lc2RGNGhSU3hack42bktkNkhYRTZnS2tlb0NF?= =?utf-8?B?SCszVmMvdkJQTGQzSm9FalUxenhZMGVQeW1tcDZUZXgxcXVZVExWb3E3WENU?= =?utf-8?B?WVlJdmF4aEFpdEViVWQvK2ozNThsOFplSDJzTFV5ZXFLVzZVV0NtOTk3YzND?= =?utf-8?B?dHJMOElmalZrL1QxT1dpbzZ6YVFUNkFoREduVEwvWllZcVBjTHJ1Z3FUcEwy?= =?utf-8?B?TUM0UTFaM0I2R0FrRW1UWXlvYzY0SE9jYkc0MTJTaDFpYVh1Zm1reXRUZXha?= =?utf-8?B?OHd3QXR6M1pDdHllbFcwNzdodFR0N3JoekpiSWNwaXhvekdzZDJZN2c0Z0Qx?= =?utf-8?B?UWx0dUpWTEhTTDk3ZlpabU5iWTUvc3NDZUR6aW9TUFgvL25iSmRKOHdXUzU3?= =?utf-8?B?aU03ZFdwVW1paHhScWM4Q2N3Ny9rTGJJOENPNFNTeGRlbk5md001UEVSRmJB?= =?utf-8?B?SnpjdHVUL3RNbmNjQ2Fkb1dSeTE3cjZURzdaUVFvQk9HZlR0SG04QTNQZEcz?= =?utf-8?B?VFBmbDdqUGZPRXNJZEw5aXVDd0szeW4vT2o3Y0VKa1RZMlZZZ3hRRU5mbnh3?= =?utf-8?B?bGZGcXI3Q0VqUVFwcVBIa2RMWE1Wcm1WYUxrcFV5ZENTeHMvbk1SMlJvZUtv?= =?utf-8?B?RGthZHd0T21ldWYyQUVWVGdxQ28xSzdwMWNJTGFvU1grTzFqVEJ5YzNyT2Vl?= =?utf-8?B?TjBCSERNanE5ZTRCNjRFNlpIK0o2eFpaczZKYllQc1ZjWGREeStac0s5TDlP?= =?utf-8?B?VzJxWmo3dFZMZFFOU01ObTk1eTNXR01LOU5hczdSOTZjQTBrQy85dDllc0Jz?= =?utf-8?B?Tll2MHJiWGtuTDNCYU44NUJMOXkyWWxCelBRYk9nUytYcE1oN2EyaWJYK3Ir?= =?utf-8?B?eG80NjFnajZyVWgwSmJMMmZZWFExMGYzekhiMU96bGF4L0ZkMTVxeWQ4cnNx?= =?utf-8?B?TnhZYkZHcStoWmVDV0pDQjZXWFJKd3dRdkw2d1UrbXZEZ2NFSHZqclJaNVJr?= =?utf-8?B?ZGo1alpjU0lhcGNueW1BeUVWVG9rL0VzU1RMK1d2UWRQSkVzNDdocVdtVG1u?= =?utf-8?B?cjRmNUh6MVk3MnlFV2MyTjkwNHBybEhSR05Yd3NLSzhKME80YVphM2w3Zmo3?= =?utf-8?B?VTAxVkFEaERQcDFFamJ0RTlhbjhBNGkrUUd4bTdiMU43RUdlRW8xQ3gwV1JE?= =?utf-8?B?QzR6ZUR4TzloQkI0MUJtYmFKUDNhTFdKUFNWdEZkY2htbERVQ2RRbGRPL25v?= =?utf-8?B?SnZRMHRZNmV0enl2c3dPM3paeGUzWFo5Z3MzVXN2ZXFBY2JYY3BJaG9jZVhq?= =?utf-8?Q?28CkPa+GDdsKP4QQTvP8=3D?= X-Microsoft-Exchange-Diagnostics: 1;AM5PR0801MB1331;6:60uFEV5S/vlKMmaY95AC/WOr0qdZTeOc/BgSd0URXN6OhhXxQvs7Q5GHRGVvJ3aT5nLVtWU8JJZNT+cRsyJOxigNOGSwhpfmqP15++1djIFdxNhYx9Z8KST5vjm7KUTh4YcSqO0KyfeoCjdLWHX3xqHL2J8PwC645u++d776RhhMlfHhNZqR/aj51avQFwkk45cdFLulqzfMM0OiqK2911ouJp3SviBb1vusywdFoOAuhUCiE31sppDi2QS7uP8PU7KOmDu+FQXU+EAK/du6YPzfNoip8Pt3xzKUEEx3bgzgZLepbbQh6ivbLyLX/Z46H5IpMI2HTUQxl2Ws38E4DeMMR2aFLTZpTlAcY3lQY6c=;5:dugOIOSDhKnu8hGso3Ua8VUV6VmLu5qHSOfsvIsv0HsbEkCLqNy+08c7fHk7Z6ZNnq/0F+73ov//cAD4F7QTn8VZgXgyu5waEyF2sDJX90vVkOeVK5MIRTONWgkXJPZ/Clfdk0VF3r05f3oF8xSxKX3bnVEeWuzJAF1f4+DWy64=;24:ebPr0n1Lb2uv7AsrrWTIQBIMo4in2tNI1fIgHMLQ/Q28Xd3mk/Bk/BC7Uw5E+nujF80fvIwdUh/5cQhOO0o4fBDVWgd969OZjcxEELyk5jY=;7:lU4bLmGhh57Vhb8VZKx4ASJ7xVqRrkFu2n+pljuiLlU3AOChJXdUpBybCZzLAYs5l14fBsLTcDNbMx8DWyFLloy70X9ZcMC1Hwf9MsXlixhQnWPaKmyvCoRgp3Tun2+6Gx8m+Dk33T4yw7/73LkRG6Y9uGbDom0+sw/PpN/5uQgko+XCLd1mXo/6skEwITXCNyP4XTs16TJRZmKCw8krG5K2rK39XPsM11Ti7EW5rJqpd+jgeozUvEs51e3BJxDM SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;AM5PR0801MB1331;20:7LLKqUTXidsDVuOG6PAPNNFt8Jo0if37b/1cuts+5lY4aSOKcgjl2yMybKacUqEyZywh5PrOAi7mB3I8rMgnLTXhw21KkFEqMfcT0fN1Tc5SW7Z6fgu3qqEtSf5Y2YI84Vrv8mjOlC6FuWsThpS0yPPGdnhz58cNVHbZsaSJKkc= X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Feb 2018 10:19:33.4502 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 12138cbb-4122-4ab2-ea3e-08d56d4b1e76 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0801MB1331 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Recent times kvmalloc() begun widely be used in kernel. Some of such memory allocations have to be freed after rcu grace period, and this patchset introduces a generic primitive for doing this. Actually, everything is made in [1/2]. Patch [2/2] is just added to make new kvfree_rcu() have the first user. The patch [1/2] transforms kfree_rcu(), its sub definitions and its sub functions into kvfree_rcu() form. The most significant change is in __rcu_reclaim(), where kvfree() is used instead of kfree(). Since kvfree() is able to have a deal with memory allocated via kmalloc(), vmalloc() and kvmalloc(); kfree_rcu() and vfree_rcu() may simply be defined through this new kvfree_rcu(). --- Kirill Tkhai (2): rcu: Transform kfree_rcu() into kvfree_rcu() mm: Use kvfree_rcu() in update_memcg_params() include/linux/rcupdate.h | 31 +++++++++++++++++-------------- include/linux/rcutiny.h | 4 ++-- include/linux/rcutree.h | 2 +- include/trace/events/rcu.h | 12 ++++++------ kernel/rcu/rcu.h | 8 ++++---- kernel/rcu/tree.c | 14 +++++++------- kernel/rcu/tree_plugin.h | 10 +++++----- mm/slab_common.c | 10 +--------- 8 files changed, 43 insertions(+), 48 deletions(-) -- Signed-off-by: Kirill Tkhai From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752749AbeBFKUJ (ORCPT ); Tue, 6 Feb 2018 05:20:09 -0500 Received: from mail-db5eur01on0111.outbound.protection.outlook.com ([104.47.2.111]:6209 "EHLO EUR01-DB5-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752248AbeBFKT4 (ORCPT ); Tue, 6 Feb 2018 05:19:56 -0500 Subject: [PATCH 1/2] rcu: Transform kfree_rcu() into kvfree_rcu() From: Kirill Tkhai To: paulmck@linux.vnet.ibm.com, josh@joshtriplett.org, rostedt@goodmis.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, ktkhai@virtuozzo.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org Date: Tue, 06 Feb 2018 13:19:45 +0300 Message-ID: <151791238553.5994.4933976056810745303.stgit@localhost.localdomain> In-Reply-To: <151791170164.5994.8253310844733420079.stgit@localhost.localdomain> References: <151791170164.5994.8253310844733420079.stgit@localhost.localdomain> User-Agent: StGit/0.18 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [195.214.232.6] X-ClientProxiedBy: VI1PR0501CA0007.eurprd05.prod.outlook.com (2603:10a6:800:92::17) To HE1PR0801MB1339.eurprd08.prod.outlook.com (2603:10a6:3:3a::7) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: a534421c-ac89-49bd-7afb-08d56d4b288c X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(7020095)(4652020)(5600026)(4604075)(4534165)(7168020)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020);SRVR:HE1PR0801MB1339; X-Microsoft-Exchange-Diagnostics: 1;HE1PR0801MB1339;3:kcsleADrTnFZgCjMZ42p8Dj32hiSK0zXM/vjans6gs1LQ6pgEBB+yWjN8CMLsIkMjUwIoLRpptxVdGLY6g6AHnRfQOouJTlWgukIBf17xxFQh1s9oP7SnB0tj2Nov8Fg1fe9CX0Ib2++s02ELVfrlmymwySdousWpUr3EmFcIwUiaP0VvXe0hPWF3LMabtTqzEOmM4E2P9AAkir270LJPXMbe0dDyVPl7GeMgX8AFeuK22ewBVpSzeeHerxKc9c1;25:n4ZhKKUqn1hmNogOOzFiZZnishWdjafgnPwRBdRXx7XZzthWA6HyeYi4A7CKjchZo7M3p6xMVtlbYTqdfH+CDvu5roRXaYWmf+NHytyab6vbvrbNL3Zgmkg98LXOONNTVL6PcJ6oq/Yf7wRWWn/tSUOVnpmvY2ZDpngvp9ps7T5yNNdBgVThcC7qpSQRmhwtT7IuUCPRRja0ZSGqcq02H37OKEW+RVUfOqV8WrWt8ysLTprESNJRaoUFsTh9jwQQHskqUJu3CTDC4d/wAB8/ONJYPuXh7wJcXjbZHeApCbg/nqC+/CbGReJnTDcZ3/i1T03zgDILzCL0EVqZ3mX60w==;31:/DCohsFsbqO61+5/wb9fIraUpnhD9YiiWBZmh7c3RG5luuFYNgtaFCOH26uxkgOPN0kpaN5klZcurM9mdOhCU+amU1cdC/L7wMPlkK5XvmoqU/NjW2I/C2uSy/j4qFjDiuuEbaoiLu9ws9y2NVp80/54BJAPDLIdE+sTJppIdI6ClBrcOSkrbhC2urBkIJ2641+s4aubJOxVFfaShB4zZK3cgBNLMlqP81utbs3YvQ4= X-MS-TrafficTypeDiagnostic: HE1PR0801MB1339: X-Microsoft-Exchange-Diagnostics: 1;HE1PR0801MB1339;20:JVKbhiHqmk3LrO+TcLtLk7UOZnmZy5LayivSi/LCqok6e4Jt1EiMjICz/WMfpHm/hAaIjvb1kAaGs0L+Fo64Tlvqm4S7z+bwavQGXMtxhAK6L0gddvKZVV4YziygYq7NGhcBw1oRiJEO1X32WtXh4iOZF5Z4U/curyQy6HgpJa6c6yHnBUhiLUoI5oQONAW7dbKoEUoAR1OIIpzYEH6/PHrdDx+PfWjGPfjLoxxMDZ0iO0+wEXSsoUuqDS4LZyRFD9tDT2pXyGfY66LECb1PKGXHVsDyoK6WreHDYOxEV1ptMWYhBS0C7OYjFFKbeQeag5zVmvR3hWNPJlwRpoTv1ftKmr0ojLZVTLltNiXzYBC5KITi+iUG6vW9gKXmYT04USqcZ+aO0W9GfDF9hMGMCgWc5+Oh1jnlEOVFvqhtKI0=;4:TH/7lOhhnUTnbuijA1B9vbzbJGzExLqticbd+HcsXD1EJ/+p2bP+KR5IV9K9aD9FnSq5/tGCqVZ0Wb3iviGNM9Ks1gIicga2Y+BkjBUrpVhPDEDpFQtO1Pn+YcRLL4XUbCVwMvxwbLde88ivtAeqN7R+Wa/LL1iQ5A11HHttqtIVt43Gfpvlfr0A8IDMjYjqa38u5gp2/fOKhdJkTkV1MIlPwSDI6n8NGvJW4p9K74Q80pYSK5HHbooOtDztCFdjQRvZ+xzHL2peCD8hTN0/R0r4tlULEzqCTpDCp5+vZ3tZBWnsZZT2RlQBafvQ7GqYqXbHYxuJ0GeTQocT638a3g== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(788757137089)(17755550239193); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040501)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(3231101)(2400082)(944501161)(10201501046)(6041288)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123560045)(20161123562045)(6072148)(201708071742011);SRVR:HE1PR0801MB1339;BCL:0;PCL:0;RULEID:;SRVR:HE1PR0801MB1339; X-Forefront-PRVS: 0575F81B58 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(6069001)(396003)(39380400002)(376002)(366004)(346002)(39840400004)(199004)(189003)(26005)(52116002)(50466002)(25786009)(2950100002)(6666003)(105586002)(47776003)(61506002)(86362001)(106356001)(8936002)(81156014)(81166006)(8676002)(66066001)(5660300001)(230700001)(68736007)(478600001)(103116003)(83506002)(2906002)(39060400002)(6116002)(58126008)(316002)(76176011)(6346003)(16526019)(186003)(55016002)(7696005)(55236004)(3846002)(386003)(9686003)(7416002)(53936002)(6506007)(33896004)(59450400001)(7736002)(2486003)(305945005)(23676004)(97736004)(921003)(1121003);DIR:OUT;SFP:1102;SCL:1;SRVR:HE1PR0801MB1339;H:localhost.localdomain;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ktkhai@virtuozzo.com; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtIRTFQUjA4MDFNQjEzMzk7MjM6bkFTMFI5WjZhRnlwQmhRL2Q1NVdneTA2?= =?utf-8?B?dHdFRUZQZys4UlJNbGY1aHJuVGRjTktKNExia2IrR083SVhCZkRtb0FWNEVw?= =?utf-8?B?ZVJYNk5ZMUhjRmV4Y0FTZXIrRDg3NGg5a1BVWkJOOTZ4S2lZMHJNM251TkhZ?= =?utf-8?B?MVlvQlJkY1VkNVNBU1VoOVFhU2hUdU5vSC9CU2dhUlpxRVdWdFdPL28zZkNU?= =?utf-8?B?dTJlUDN2cTg1YzZiUnFyZmRsRUFvNE9zVUNPYXZZLzJZQS93bW8xSmg3TW5t?= =?utf-8?B?dmQ3TU9tSFZrSlJIM2w1NWJ4TnBXd2sxaTRYeXFzYmw2VkZtV1VwRmZYSHF1?= =?utf-8?B?UDdtTitQanJBRGgreUl1dFA2M3RPenY4cTY4OUliWk92S0JQUjBMWUNLYVAv?= =?utf-8?B?NmtHRWVBY3FJd1VPOUZGdmRwU0t1RytlRzBrekIxRGxtVDloYk9wQkdJK2lS?= =?utf-8?B?VGV3ZUNRai90b0tYM3dzaGNKaFJrOFhwU0EzWHRYVkl1Q1UyTDVDMXJkT3FQ?= =?utf-8?B?OWtTUzE3RUVSMHMrcjN1Q2tLd2J5MkJPTUZHVHFCZmFNVkQ3aDZJSlRDSmZB?= =?utf-8?B?VExSM0NyNWxudHl2YnpQQjR3Zy9wYkMzeTduRTJncko0UmU4R2V3OTFBN3hH?= =?utf-8?B?VGR5Q1lkZlIxT0xxc0o2SW94dHBPZk5tVHRKTHp2ZTQrc3JNb1Z4WlBkSXJC?= =?utf-8?B?bnFzeTQwcUo5VTJqS0h4eCtKTlRWaDlEQnFST3pqaGJpMjM3K0N2OHVxT1FF?= =?utf-8?B?YkltU1dIM1A3cFc0SGZhTWV4WnBIRjg5SzgycmRRTkJFWUkxQ2hLQldaMHBM?= =?utf-8?B?WCt2VG9vWkVkbmNRZTRVSk4wYUloMEc3U2Q5SHJYZjN6THhzYUZxTnhkRnF1?= =?utf-8?B?Z2IyRVg1U0NQTTduMkErZXJtczlNMnd3Y0JIT0hlNXhpVzhMN0FUUjNPTUZ4?= =?utf-8?B?bC9SR2NOOVhMR1B2UGVpY1ZMUldwRkw3OStjeXFpMzZrc1B4ZlBTMHJtRStL?= =?utf-8?B?WmpUMGxBRW16M3M2YVI3QUFFTDkveWJFU3hDY3VHK0JjMllqRUFRdS84Wk03?= =?utf-8?B?Y2krNHhwc1RsTnpHMXVQdmIxa3BjTVNLaXphbWxhWjYwQTJpckxlZzRubDNz?= =?utf-8?B?djJIeGgwQm40VUpmK0FDRS8yT3JQODU0SjdRd0pmenRSQkRtTU5reFBJQk4v?= =?utf-8?B?N0FJUmxXd1NGUHBha0FySEd2RkFwUHprdmlCeU4yQWVjSThuZWRCNWoyRDcz?= =?utf-8?B?bk5YUHVvaVpPMTBYOTZDcCt1RjZqQmFPQ1k3VlVKMzRlVkREeXZzd01UUkpy?= =?utf-8?B?TmR0dlJhQWVrZENMS1piNTVERXgzbW0yaEp6TWZRSU0wSEt0dnpSNzVCNXlL?= =?utf-8?B?L2YxN05LRkIvbi85RTdTVnZGMDFGS2hmdVhjMTdXVXlrMC9RVExOU0xaWjA1?= =?utf-8?B?VTVzdW1LNEpXeXJSeWdpeGpwTVpnbGJQb3FyU1pJZnJkUGxwc013amJnUHlL?= =?utf-8?B?Q0NGaVNoc0FZekxNZ3k1YWFKbTZOUWxTdHZHU1h6bGV3VTJ4akQrMnRuMDN4?= =?utf-8?B?bWpHSkk4U0xvZThOOEd6bXc4NFZjbjNjenZ0WGJKS2lOY3YzdWxYMkFqY0NS?= =?utf-8?B?RUhOTDNHOGoyOEpNNTN4SytmdmsybllyMmI3ZDF5cDVUbU1XakR1b0hYQThp?= =?utf-8?B?Q3hUa2JGcDI1QjVnamFycnFlL3FET1A4Mmhpd0crUGUxNElRN2xLU3ZZc1NT?= =?utf-8?Q?JzHlh5T62p7ekC8uHSTK1REuIwEnnXhsWLn0SFc=3D?= X-Microsoft-Exchange-Diagnostics: 1;HE1PR0801MB1339;6:7dsNGXPOh+Is4voLfuakdddmwf/IXqWNXrQvqacf8FSVycRQSde6u/wAfsfYI6NQvn/jDw9bosItgGdHxHFQOYpI72oNARPdM3UHIT9MhvJp9aprMJGAvHxiYvnxF3Mjkwa2pIwQdX9gyHImVJ9AqAYvRkDcCnRSUBAlsmlgVkQamie0Cs0HhakHJUWH+BE7/dJNgqi3ePn9FL51Uvv9gXS7awTPV+Qp+NzUIjfZA+caWU1eNzjOFdaI+p+rONCTmkM32lPF6o+Khw/9jfxpb8EK5PbXFC65gBzTf9EAX167pMd5TqK/spPqnhbFREKAPOSSi2XmcojdDkyKQmni8GtE0hzMtLBdBj5jQ6CGEoU=;5:BgPhnyyqgb0FX9DoBTM6BDZstYmzXbGHDN+OnMTQtir6C3ShcqFM+Ge+jVFKWhbgCafNdMU3dcknOnw1QFbY7A7QdiT8t5A+Kjh3YHkbqblaSlBt8ZzyWFyh/m+tVxO7el/RjgX7uhfgwxukra/vq5JByTjzOH42OMMSHZgzI1Y=;24:NVUsrx/VuFP2kwoteqRsl7AC34Vdk9xkkrzo6LhOMAJx3LlDISPWdBQkidaXmoNSdCB0imrWYiEdxi5YzdJs8WCKf6o4s1CO+nWETGFCKeQ=;7:1A4NKG8savSN04ur6LPoG4xhnEvb00hxVlhzClZ6hg0Yc4tES7P3RP5w53CZdPf6cRj95wIcStd6edSqbAssVRgb9rAuvffp2oype44tugT1RkHHAYSk/+pNFy4nE5cWYIa5NYIDzke7tAxIq3bzECsgVEKYdBNXYPhboWb7v679z6B5ZDiLLqLG4gB5ScKkX++usXcitcWlWhGx8FbVJPQCykGka1kIZFnEa7x/83d3x9qQkzFLvDWpwgsjx9jf SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;HE1PR0801MB1339;20:8m2yhQ+qS1vivOIMeZwLJbm5ihY3w0857lZcd7g/TLf7Jh6NK4giyfNXrTWZVvccV0SXQD7n5hgp59qAGviRQ5ojAzkf+KrHxOmuSbADByoxWv7N8SJNnK/0FBixg41KteNxhuCxmj+VJy/qUtWLF3wdE1ze4UAWJrZDoKag6uY= X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Feb 2018 10:19:49.7749 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: a534421c-ac89-49bd-7afb-08d56d4b288c X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0801MB1339 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Recent times kvmalloc() begun widely be used in kernel. Some of such memory allocations have to be freed after rcu grace period, and this patch introduces a generic primitive for doing this. Currently, there is kfree_rcu() primitive in kernel, which encodes rcu_head offset inside freed structure on place of callback function. We can simply reuse it and replace final kfree() in __rcu_reclaim() with kvfree(). Since this primitive is able to free memory allocated via kmalloc(), vmalloc() and kvmalloc(), we may have single kvfree_rcu(), and define kfree_rcu() and vfree_rcu() through it. This allows users to avoid to implement custom functions for destruction kvmalloc()'ed and vmalloc()'ed memory. The new primitive kvfree_rcu() are used since next patch. Signed-off-by: Kirill Tkhai --- include/linux/rcupdate.h | 31 +++++++++++++++++-------------- include/linux/rcutiny.h | 4 ++-- include/linux/rcutree.h | 2 +- include/trace/events/rcu.h | 12 ++++++------ kernel/rcu/rcu.h | 8 ++++---- kernel/rcu/tree.c | 14 +++++++------- kernel/rcu/tree_plugin.h | 10 +++++----- 7 files changed, 42 insertions(+), 39 deletions(-) diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h index 043d04784675..22d4086f50b2 100644 --- a/include/linux/rcupdate.h +++ b/include/linux/rcupdate.h @@ -832,36 +832,36 @@ static inline notrace void rcu_read_unlock_sched_notrace(void) /* * Does the specified offset indicate that the corresponding rcu_head - * structure can be handled by kfree_rcu()? + * structure can be handled by kvfree_rcu()? */ -#define __is_kfree_rcu_offset(offset) ((offset) < 4096) +#define __is_kvfree_rcu_offset(offset) ((offset) < 4096) /* - * Helper macro for kfree_rcu() to prevent argument-expansion eyestrain. + * Helper macro for kvfree_rcu() to prevent argument-expansion eyestrain. */ -#define __kfree_rcu(head, offset) \ +#define __kvfree_rcu(head, offset) \ do { \ - BUILD_BUG_ON(!__is_kfree_rcu_offset(offset)); \ - kfree_call_rcu(head, (rcu_callback_t)(unsigned long)(offset)); \ + BUILD_BUG_ON(!__is_kvfree_rcu_offset(offset)); \ + kvfree_call_rcu(head, (rcu_callback_t)(unsigned long)(offset)); \ } while (0) /** - * kfree_rcu() - kfree an object after a grace period. - * @ptr: pointer to kfree + * kvfree_rcu() - kvfree an object after a grace period. + * @ptr: pointer to kvfree * @rcu_head: the name of the struct rcu_head within the type of @ptr. * - * Many rcu callbacks functions just call kfree() on the base structure. + * Many rcu callbacks functions just call kvfree() on the base structure. * These functions are trivial, but their size adds up, and furthermore * when they are used in a kernel module, that module must invoke the * high-latency rcu_barrier() function at module-unload time. * - * The kfree_rcu() function handles this issue. Rather than encoding a - * function address in the embedded rcu_head structure, kfree_rcu() instead + * The kvfree_rcu() function handles this issue. Rather than encoding a + * function address in the embedded rcu_head structure, kvfree_rcu() instead * encodes the offset of the rcu_head structure within the base structure. * Because the functions are not allowed in the low-order 4096 bytes of * kernel virtual memory, offsets up to 4095 bytes can be accommodated. * If the offset is larger than 4095 bytes, a compile-time error will - * be generated in __kfree_rcu(). If this error is triggered, you can + * be generated in __kvfree_rcu(). If this error is triggered, you can * either fall back to use of call_rcu() or rearrange the structure to * position the rcu_head structure into the first 4096 bytes. * @@ -871,9 +871,12 @@ static inline notrace void rcu_read_unlock_sched_notrace(void) * The BUILD_BUG_ON check must not involve any function calls, hence the * checks are done in macros here. */ -#define kfree_rcu(ptr, rcu_head) \ - __kfree_rcu(&((ptr)->rcu_head), offsetof(typeof(*(ptr)), rcu_head)) +#define kvfree_rcu(ptr, rcu_head) \ + __kvfree_rcu(&((ptr)->rcu_head), offsetof(typeof(*(ptr)), rcu_head)) +#define kfree_rcu(ptr, rcu_head) kvfree_rcu(ptr, rcu_head) + +#define vfree_rcu(ptr, rcu_head) kvfree_rcu(ptr, rcu_head) /* * Place this after a lock-acquisition primitive to guarantee that diff --git a/include/linux/rcutiny.h b/include/linux/rcutiny.h index ce9beec35e34..2e484aaa534f 100644 --- a/include/linux/rcutiny.h +++ b/include/linux/rcutiny.h @@ -84,8 +84,8 @@ static inline void synchronize_sched_expedited(void) synchronize_sched(); } -static inline void kfree_call_rcu(struct rcu_head *head, - rcu_callback_t func) +static inline void kvfree_call_rcu(struct rcu_head *head, + rcu_callback_t func) { call_rcu(head, func); } diff --git a/include/linux/rcutree.h b/include/linux/rcutree.h index fd996cdf1833..4d6365be4504 100644 --- a/include/linux/rcutree.h +++ b/include/linux/rcutree.h @@ -48,7 +48,7 @@ void synchronize_rcu_bh(void); void synchronize_sched_expedited(void); void synchronize_rcu_expedited(void); -void kfree_call_rcu(struct rcu_head *head, rcu_callback_t func); +void kvfree_call_rcu(struct rcu_head *head, rcu_callback_t func); /** * synchronize_rcu_bh_expedited - Brute-force RCU-bh grace period diff --git a/include/trace/events/rcu.h b/include/trace/events/rcu.h index 0b50fda80db0..9507264fa8f8 100644 --- a/include/trace/events/rcu.h +++ b/include/trace/events/rcu.h @@ -496,13 +496,13 @@ TRACE_EVENT(rcu_callback, /* * Tracepoint for the registration of a single RCU callback of the special - * kfree() form. The first argument is the RCU type, the second argument + * kvfree() form. The first argument is the RCU type, the second argument * is a pointer to the RCU callback, the third argument is the offset * of the callback within the enclosing RCU-protected data structure, * the fourth argument is the number of lazy callbacks queued, and the * fifth argument is the total number of callbacks queued. */ -TRACE_EVENT(rcu_kfree_callback, +TRACE_EVENT(rcu_kvfree_callback, TP_PROTO(const char *rcuname, struct rcu_head *rhp, unsigned long offset, long qlen_lazy, long qlen), @@ -591,12 +591,12 @@ TRACE_EVENT(rcu_invoke_callback, /* * Tracepoint for the invocation of a single RCU callback of the special - * kfree() form. The first argument is the RCU flavor, the second + * kvfree() form. The first argument is the RCU flavor, the second * argument is a pointer to the RCU callback, and the third argument * is the offset of the callback within the enclosing RCU-protected * data structure. */ -TRACE_EVENT(rcu_invoke_kfree_callback, +TRACE_EVENT(rcu_invoke_kvfree_callback, TP_PROTO(const char *rcuname, struct rcu_head *rhp, unsigned long offset), @@ -767,12 +767,12 @@ TRACE_EVENT(rcu_barrier, #define trace_rcu_fqs(rcuname, gpnum, cpu, qsevent) do { } while (0) #define trace_rcu_dyntick(polarity, oldnesting, newnesting, dyntick) do { } while (0) #define trace_rcu_callback(rcuname, rhp, qlen_lazy, qlen) do { } while (0) -#define trace_rcu_kfree_callback(rcuname, rhp, offset, qlen_lazy, qlen) \ +#define trace_rcu_kvfree_callback(rcuname, rhp, offset, qlen_lazy, qlen) \ do { } while (0) #define trace_rcu_batch_start(rcuname, qlen_lazy, qlen, blimit) \ do { } while (0) #define trace_rcu_invoke_callback(rcuname, rhp) do { } while (0) -#define trace_rcu_invoke_kfree_callback(rcuname, rhp, offset) do { } while (0) +#define trace_rcu_invoke_kvfree_callback(rcuname, rhp, offset) do { } while (0) #define trace_rcu_batch_end(rcuname, callbacks_invoked, cb, nr, iit, risk) \ do { } while (0) #define trace_rcu_torture_read(rcutorturename, rhp, secs, c_old, c) \ diff --git a/kernel/rcu/rcu.h b/kernel/rcu/rcu.h index 6334f2c1abd0..696200886098 100644 --- a/kernel/rcu/rcu.h +++ b/kernel/rcu/rcu.h @@ -151,7 +151,7 @@ static inline void debug_rcu_head_unqueue(struct rcu_head *head) } #endif /* #else !CONFIG_DEBUG_OBJECTS_RCU_HEAD */ -void kfree(const void *); +void kvfree(const void *); /* * Reclaim the specified callback, either by invoking it (non-lazy case) @@ -162,9 +162,9 @@ static inline bool __rcu_reclaim(const char *rn, struct rcu_head *head) unsigned long offset = (unsigned long)head->func; rcu_lock_acquire(&rcu_callback_map); - if (__is_kfree_rcu_offset(offset)) { - RCU_TRACE(trace_rcu_invoke_kfree_callback(rn, head, offset);) - kfree((void *)head - offset); + if (__is_kvfree_rcu_offset(offset)) { + RCU_TRACE(trace_rcu_invoke_kvfree_callback(rn, head, offset);) + kvfree((void *)head - offset); rcu_lock_release(&rcu_callback_map); return true; } else { diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index 491bdf39f276..8e736aa11a46 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -3061,10 +3061,10 @@ __call_rcu(struct rcu_head *head, rcu_callback_t func, if (!lazy) rcu_idle_count_callbacks_posted(); - if (__is_kfree_rcu_offset((unsigned long)func)) - trace_rcu_kfree_callback(rsp->name, head, (unsigned long)func, - rcu_segcblist_n_lazy_cbs(&rdp->cblist), - rcu_segcblist_n_cbs(&rdp->cblist)); + if (__is_kvfree_rcu_offset((unsigned long)func)) + trace_rcu_kvfree_callback(rsp->name, head, (unsigned long)func, + rcu_segcblist_n_lazy_cbs(&rdp->cblist), + rcu_segcblist_n_cbs(&rdp->cblist)); else trace_rcu_callback(rsp->name, head, rcu_segcblist_n_lazy_cbs(&rdp->cblist), @@ -3134,14 +3134,14 @@ EXPORT_SYMBOL_GPL(call_rcu_bh); * This will likely be later named something like "call_rcu_lazy()", * but this change will require some way of tagging the lazy RCU * callbacks in the list of pending callbacks. Until then, this - * function may only be called from __kfree_rcu(). + * function may only be called from __kvfree_rcu(). */ -void kfree_call_rcu(struct rcu_head *head, +void kvfree_call_rcu(struct rcu_head *head, rcu_callback_t func) { __call_rcu(head, func, rcu_state_p, -1, 1); } -EXPORT_SYMBOL_GPL(kfree_call_rcu); +EXPORT_SYMBOL_GPL(kvfree_call_rcu); /* * Because a context switch is a grace period for RCU-sched and RCU-bh, diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h index fb88a028deec..85715963658e 100644 --- a/kernel/rcu/tree_plugin.h +++ b/kernel/rcu/tree_plugin.h @@ -1984,11 +1984,11 @@ static bool __call_rcu_nocb(struct rcu_data *rdp, struct rcu_head *rhp, if (!rcu_is_nocb_cpu(rdp->cpu)) return false; __call_rcu_nocb_enqueue(rdp, rhp, &rhp->next, 1, lazy, flags); - if (__is_kfree_rcu_offset((unsigned long)rhp->func)) - trace_rcu_kfree_callback(rdp->rsp->name, rhp, - (unsigned long)rhp->func, - -atomic_long_read(&rdp->nocb_q_count_lazy), - -atomic_long_read(&rdp->nocb_q_count)); + if (__is_kvfree_rcu_offset((unsigned long)rhp->func)) + trace_rcu_kvfree_callback(rdp->rsp->name, rhp, + (unsigned long)rhp->func, + -atomic_long_read(&rdp->nocb_q_count_lazy), + -atomic_long_read(&rdp->nocb_q_count)); else trace_rcu_callback(rdp->rsp->name, rhp, -atomic_long_read(&rdp->nocb_q_count_lazy), From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752719AbeBFKUW (ORCPT ); Tue, 6 Feb 2018 05:20:22 -0500 Received: from mail-eopbgr20103.outbound.protection.outlook.com ([40.107.2.103]:63426 "EHLO EUR02-VE1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752710AbeBFKUF (ORCPT ); Tue, 6 Feb 2018 05:20:05 -0500 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ktkhai@virtuozzo.com; Subject: [PATCH 2/2] mm: Use kvfree_rcu() in update_memcg_params() From: Kirill Tkhai To: paulmck@linux.vnet.ibm.com, josh@joshtriplett.org, rostedt@goodmis.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, ktkhai@virtuozzo.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org Date: Tue, 06 Feb 2018 13:19:56 +0300 Message-ID: <151791239671.5994.2058061081618636334.stgit@localhost.localdomain> In-Reply-To: <151791170164.5994.8253310844733420079.stgit@localhost.localdomain> References: <151791170164.5994.8253310844733420079.stgit@localhost.localdomain> User-Agent: StGit/0.18 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [195.214.232.6] X-ClientProxiedBy: VI1PR0202CA0003.eurprd02.prod.outlook.com (2603:10a6:803:14::16) To VI1PR0801MB1342.eurprd08.prod.outlook.com (2603:10a6:800:3a::28) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 756d8ada-4a12-4731-5cce-08d56d4b2e3e X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(7020095)(4652020)(5600026)(4604075)(4534165)(7168020)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020);SRVR:VI1PR0801MB1342; X-Microsoft-Exchange-Diagnostics: 1;VI1PR0801MB1342;3:/CalB1iCqbI/7wZvFVY9IbFIRpopBWLmo89OiSLUDYjS1ACPtKWncHq8n5umjFFar7n0kQbDuWxeCzeURYEygV8tk3/8veV8tBTaKpZeE++B+i2FS3M2PX+OLKOZBuKgMCwWGYDymGe62rE6l1SAZGZVzwmynYjexQzIgTAGwjjbIHnB6E1sO9AeD0169QOkg0iI4wMBtvdAnpOPqcsYsefIJUseioG/uxmv6nzA5Aek0Yplqhr6uQymgnDhnxcJ;25:U5tpodWcHsJ8DTlHXBnJmFEFFjxdVR8iWdxE/TyQRCzBaGceqFgUctE94AuG5dsylRxtTcQj2LyDUnprN8Zsb1XvipLk4H6uDDrF2aPqK8q2SrnWobWgd/6Mr+w7S75iO6u1NNNTPF6UnXxgi3DZjAV+4JmaD0WDEu6vbHF5B/SWgU+A5zxE/U6+A/46KHOinqyFWhIHwVRdGM7yNT0EsJ2NrGNo9FzGDuWZF89jHkEbhRph/QzNmFtDRRfPs3ZZXmvneJdKRkGaVP98ZhsrwOfeiajV7y1yJMa+vpGUqHTT+F9cgeCOFMYObxEzl0tB/0//b/K3rgYrxx454PGWtQ==;31:kdLK1MrmCWiuwSyN39rTB39ea9mCU4hq8IIiFarWuf8wYgwB70eBFdaLnCmACzTaYHgJXdVFufrDnNbeyiMGRhc0icaibb5OjhMP+A4Ewd8Igdbi72Fl4jQZoFd7CcZdNEv7AFqTnSBwU8YGCOcnTOC676N0cwrgSOG/363LDPtQL8dlj0yVZKgW6B63GOubJqcAs1GCLeG7CSqhJ/spUyzqXwqWf+Z3+7RR7bNopd4= X-MS-TrafficTypeDiagnostic: VI1PR0801MB1342: X-Microsoft-Exchange-Diagnostics: 1;VI1PR0801MB1342;20:TEBhRGIA/A3u0PfK3lcH0NF1Ybvk+DV2DF6i31kk7o1SSUfITBT33/5B99SOJimTW4fF7WE5aIcWSfJq+FkWSJjUpmhmNpApPB0JU4BLg8cLM4yHVCtqp8SNGx3Rn1/VgsGopNYvuZ565uUPC7fC/tLyOhxgJ+zG48PSw2YvuREcMWhXy46CXh957xXgKLUHZ+cvxyABeDOx0oMDj4dT8JPVT+U4hxxa8hd+D0cCvx8EJpqgIvmlcekejZ1tIKcs/dKxi0KKylPhC2zhPa1GM24LxlgwNlziQVg5fRrXVb+GC+bK2CX0PspyrfWgjPK3n4qi86Fg42gWglvNfMHgVysmCQMrumGYc/muA05p4rC1trjJAAywJzZ0J3CukbEAG9Er+omlOIew0pFVLxjXFm4ZRf8yvZZ6k7X/lJmh1i0=;4:/tUGj6DL0AaFXGjyjej1L0Q/yGwATc3pBU0pKtlgbrexOHDipO60OkcqmWsuu964jkUFW/LmEbZw/8X1KTex9h+BtB4jklKpS+hWsbmJEwG5Xz8oSOhzLdO68/RLD6vtvwHxSJjwds2ZrbPhNkTUb+tMvcgRoLi5ADOyPIdESw2OsS+lgpnTHIdbBLpP3mpTW/oSpoi7tgl1gdEZ058XztrS0Tx7XJSU7Z2S5qCOWDN2Xc7FxH3ATNunrT747e7yDfhkB0/3YNohPGAICtnnew== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040501)(2401047)(5005006)(8121501046)(3002001)(3231101)(2400082)(944501161)(93006095)(93001095)(10201501046)(6041288)(20161123562045)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011);SRVR:VI1PR0801MB1342;BCL:0;PCL:0;RULEID:;SRVR:VI1PR0801MB1342; X-Forefront-PRVS: 0575F81B58 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(6069001)(39840400004)(366004)(396003)(346002)(376002)(39380400002)(199004)(189003)(8676002)(7736002)(305945005)(81166006)(81156014)(8936002)(68736007)(39060400002)(53936002)(105586002)(86362001)(97736004)(66066001)(61506002)(47776003)(2950100002)(25786009)(6666003)(5660300001)(7416002)(15650500001)(106356001)(6116002)(103116003)(3846002)(50466002)(386003)(76176011)(6506007)(55236004)(52116002)(2486003)(23676004)(55016002)(33896004)(230700001)(26005)(478600001)(59450400001)(7696005)(9686003)(16526019)(186003)(316002)(2906002)(83506002)(58126008)(921003)(1121003);DIR:OUT;SFP:1102;SCL:1;SRVR:VI1PR0801MB1342;H:localhost.localdomain;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtWSTFQUjA4MDFNQjEzNDI7MjM6cnhlZkhBVTRjZkQ3OUk0VmtXempES0hC?= =?utf-8?B?M3BGYUtvZUdvL1JuRnV1ODlnZUJ5YUw1aXA4UnlIc1E4d1kxeFcrNDFMYWtE?= =?utf-8?B?UlJwWVpLeGJhWllzeFdpUG5YZytrYXJRR1JreC9OZlRCZkY5a2k2TEVLb1lN?= =?utf-8?B?cDEwSEppWDZKRGpQZTJHaGdkTUsxd1F2RVJEeVNVK2p3ZnphTUtkY0YyUTEv?= =?utf-8?B?S3BGMkpmelFGVEtrMndIeDFzOTQzYWxiVmx1V3dqS0pXdkUyYUszaldiODdE?= =?utf-8?B?ZE9LanRwd2JINEsvWitpN0V6d2UwdURyd0dJYmFBc2RNYmpqM1NxYzlKbnJw?= =?utf-8?B?eEVEeCtvLzJFWVUxZnBKVHZJMFdSVUJtVEU0M3JRNU5TV3BXVVpMeGlxMGky?= =?utf-8?B?Z1ZMSzZLbVlXQnhPRmlFMlhSb1VvSENZSmV1NU02S1JGRlY4R3hzUm5GY05w?= =?utf-8?B?NGplS25STkFpaEwrRkczcUJ6YThEZmVpVmRWeUNzVlFlclZveDhwaFRZQjhp?= =?utf-8?B?KzB6VC82RHdPeWVPL2FSWW5UeHZBMTVBQVNEUzk5MFQ1YkVzV3hYRTF3dmFo?= =?utf-8?B?T2JRVjdEUGM0WndlZmZISTA1N0FwMURyYzVqUytNSHNlRFg1NzlOM3dSbGFH?= =?utf-8?B?NldaWjkrYnVCMEJpY2s0RGtKNk5oMEFBQlZlUUdtY0xEU0hPNCtrN3k1OGRY?= =?utf-8?B?MGpRaWpkS2xkRXdXWEZOYTEwM0Y1VjBjQy8vTTFaSzd6VmZPWFAyQ3krNUpq?= =?utf-8?B?cERtZVBMaWFQcUlxeFVEcnJxeWN3UVdoR05QMU9TV3poS2pCRFRjUEF1UHgw?= =?utf-8?B?TXJhdGZHVHlQQld2eXdka1dZNDNSTFl5algvNzlVdUEwS0FIVUw1ZDdueFUr?= =?utf-8?B?QUFZMlZsellZVWhCOVdydm5QRjJyR2VtYmExZ3FkRWczUDh1UjZWaldCQTFW?= =?utf-8?B?T3hocUt6WTRVSzVYM0RydjFmZkw0ejBRa25GQ1R4Qkp0cEkxZDE3RnFoWDIx?= =?utf-8?B?SllFemJjQVlDeWs0OGo0RFpoMVYzYUt3QXVLSzRtcmIyOFc4T29rSTVGMGow?= =?utf-8?B?VS82eTRhWlcvT1I5R1oySUliRlpKR3pyYTRMYmZUVzBRdzVzSlFGQ3RsY1Fk?= =?utf-8?B?cU4xdVp5dmpyQ0JrSmFQK1VrK3NZZVlHZHEyTTVtZ29vVUI3aUp6NjFCN2Jl?= =?utf-8?B?MEhOVWY4Y2J6dHlqV05lZDFuTWhkK21NNTYyZWJ0UXBMQzJoMkViSU5MaUd4?= =?utf-8?B?OFhnZmlGYUtWU1ZXSXVYN3JnRzRlQVl6amw1NmJBRk01YVFCTWFpOFNRdW9y?= =?utf-8?B?cmRPclhuMG5CTmJJdU1sRk9kU3pJNnJWcWRUQWlVRWJrUGQrZGMvU1gwVElo?= =?utf-8?B?cXk4REhLeVc5d0NpaS80L09XK0NZSkY0YnppeW03Q2pETzRaQ0dZbUFUbnF3?= =?utf-8?B?YVg5dkhhSWluelIxbGdSWlFTNCtpZDEwQk9QRHkxb28zZnQ3cWJlUys1a0dw?= =?utf-8?B?STV4a2Z4M1FYVWR6eG9IZWpZczd4UlRwbTFzTFZDYlR4cHNCMWdMNHlOOWUr?= =?utf-8?B?NzNUdUF0b1BqOGlVNkFSUUx3Q20rclprNnJuVE51dXdybHpMTU5XM3dQbWhM?= =?utf-8?B?ZmtHNzcyYk96cS9KM3BObkt5d1VYWU96eU5YRTMyVUFyVGFibVBLQnRFWGor?= =?utf-8?B?djI2RCtjQlNHdk44anN0c1VsQzlvS0M4OWs4b3ZCbC9vOVh5alRCNE1xNGhs?= =?utf-8?Q?tzQAQgNE/6m406tVUIVmwDfHreqvlmsG82sKI74=3D?= X-Microsoft-Exchange-Diagnostics: 1;VI1PR0801MB1342;6:XC7zg8E1f5P52s0OMIffJYKcE1KtXKT8ib1/eEkyqwlA8yZTrCabvcglMvFo9Bd3oza2yQcn8Aca2UpbU1+uutJZ1kXoqUJsjYh1ZRae3aYPqUIh4FjFYRktNypPAuylN5CpcnFF0e/KQbMHTQ9ERNukcJgfLPzkeA/sr/c0Apwcq4B123t+8IzvDArAv1ScnwMXV1zCt3igj05D1urxMypX9Ag73WoLkqxNxmbIA1ai8UiYq3mP90M/U6AwziyV9zTJxgf5sfBAoN/fT+iCIBUbipNCcse+ZBJ+mn5CPyd42eRPtU5L5CBwWUTFaKjwM9yWzJos1nYSzIXZei2HldEcJ55YrhZigkmsm/vYEWQ=;5:X2/E+rdhdYNuyV9ziQkprIbhiu7dboiEX2OFvtXmHn7UJwEwxFg78K/0voCfEstYdyKJL6iHq9leYCdURaBjFoAFYbZpkTen0tb8t4VFZjOTBVKQPISQA8UlVfWRz8XRY0n7aJIkPRrYSe3rC5THhc2mnv+QL5DEfRKRKcbn5tk=;24:YXQOZtHcAQTALYP9+Bmaf+LlHDce686TI4iw6xi5EX7Wa7Q7MznqZWNe16uclcIDoehXkDirNKuuKeSqjUnOTX+hhqDdOAy76aEeTgaXPoY=;7:9glKnDPCoSJfKwwqatUb2zYtlFdlwzvPD/KAGlrlFI1kDw5Rsugqi0xCG+5nYsun6Jn3qnXUGHBPLd8Ng1pyxuMCB1hVYSe5NAxeh6prfsZK7ap2kUI7ubbBtl9Pn2oUhWjnEjEtJMg5gRK5X+Zi/j9aSh4mKJj44dlnFtg2NdoVGwUgz0r9TJ4OARk0umsOMViOParZc1cksdXp+7/dy8go+si/b5tP5ocqK23efXH3MmmrQu7yJLO6kB+AVCZV SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;VI1PR0801MB1342;20:snzqFpmOuniwr8C8y++MQUNN5GWvQb1z8N8I8lU2m2xBYfJRA8o0IC3TX4Uc6OSy4jSKyj4QpABuVQaWjvVgvqt8kFyd15GoLmXZFnf2axG61aLVJIlE8vb72NtdzsXu0kV0UnW7OvC1TzDaweIb0+sC0h2i6YMFmHdfviN4VXU= X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Feb 2018 10:20:00.0012 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 756d8ada-4a12-4731-5cce-08d56d4b2e3e X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1342 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Make update_memcg_params() to use generic kvfree_rcu() helper and remove free_memcg_params() code. Signed-off-by: Kirill Tkhai --- mm/slab_common.c | 10 +--------- 1 file changed, 1 insertion(+), 9 deletions(-) diff --git a/mm/slab_common.c b/mm/slab_common.c index 10f127b2de7c..92d4a3a9471d 100644 --- a/mm/slab_common.c +++ b/mm/slab_common.c @@ -190,14 +190,6 @@ static void destroy_memcg_params(struct kmem_cache *s) kvfree(rcu_access_pointer(s->memcg_params.memcg_caches)); } -static void free_memcg_params(struct rcu_head *rcu) -{ - struct memcg_cache_array *old; - - old = container_of(rcu, struct memcg_cache_array, rcu); - kvfree(old); -} - static int update_memcg_params(struct kmem_cache *s, int new_array_size) { struct memcg_cache_array *old, *new; @@ -215,7 +207,7 @@ static int update_memcg_params(struct kmem_cache *s, int new_array_size) rcu_assign_pointer(s->memcg_params.memcg_caches, new); if (old) - call_rcu(&old->rcu, free_memcg_params); + kvfree_rcu(old, rcu); return 0; } From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752331AbeBFOfB (ORCPT ); Tue, 6 Feb 2018 09:35:01 -0500 Received: from mail.kernel.org ([198.145.29.99]:47934 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752061AbeBFOey (ORCPT ); Tue, 6 Feb 2018 09:34:54 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D546E208FE Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=goodmis.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=rostedt@goodmis.org Date: Tue, 6 Feb 2018 09:34:51 -0500 From: Steven Rostedt To: Kirill Tkhai Cc: paulmck@linux.vnet.ibm.com, 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 Subject: Re: [PATCH 1/2] rcu: Transform kfree_rcu() into kvfree_rcu() Message-ID: <20180206093451.0de5ceeb@gandalf.local.home> In-Reply-To: <151791238553.5994.4933976056810745303.stgit@localhost.localdomain> References: <151791170164.5994.8253310844733420079.stgit@localhost.localdomain> <151791238553.5994.4933976056810745303.stgit@localhost.localdomain> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 06 Feb 2018 13:19:45 +0300 Kirill Tkhai wrote: > /** > - * kfree_rcu() - kfree an object after a grace period. > - * @ptr: pointer to kfree > + * kvfree_rcu() - kvfree an object after a grace period. > + * @ptr: pointer to kvfree > * @rcu_head: the name of the struct rcu_head within the type of @ptr. > * You may want to add a big comment here that states this works for both free vmalloc and kmalloc data. Because if I saw this, I would think it only works for vmalloc, and start implementing a custom one for kmalloc data. -- Steve > - * Many rcu callbacks functions just call kfree() on the base structure. > + * Many rcu callbacks functions just call kvfree() on the base structure. > * These functions are trivial, but their size adds up, and furthermore > * when they are used in a kernel module, that module must invoke the > * high-latency rcu_barrier() function at module-unload time. > * > - * The kfree_rcu() function handles this issue. Rather than encoding a > - * function address in the embedded rcu_head structure, kfree_rcu() instead > + * The kvfree_rcu() function handles this issue. Rather than encoding a > + * function address in the embedded rcu_head structure, kvfree_rcu() instead > * encodes the offset of the rcu_head structure within the base structure. > * Because the functions are not allowed in the low-order 4096 bytes of > * kernel virtual memory, offsets up to 4095 bytes can be accommodated. > * If the offset is larger than 4095 bytes, a compile-time error will > - * be generated in __kfree_rcu(). If this error is triggered, you can > + * be generated in __kvfree_rcu(). If this error is triggered, you can > * either fall back to use of call_rcu() or rearrange the structure to > * position the rcu_head structure into the first 4096 bytes. > * > @@ -871,9 +871,12 @@ static inline notrace void rcu_read_unlock_sched_notrace(void) > * The BUILD_BUG_ON check must not involve any function calls, hence the > * checks are done in macros here. > */ > -#define kfree_rcu(ptr, rcu_head) \ > - __kfree_rcu(&((ptr)->rcu_head), offsetof(typeof(*(ptr)), rcu_head)) > +#define kvfree_rcu(ptr, rcu_head) \ > + __kvfree_rcu(&((ptr)->rcu_head), offsetof(typeof(*(ptr)), rcu_head)) > > +#define kfree_rcu(ptr, rcu_head) kvfree_rcu(ptr, rcu_head) > + > +#define vfree_rcu(ptr, rcu_head) kvfree_rcu(ptr, rcu_head) > > /* > * Place this after a lock-acquisition primitive to guarantee that > diff --git a/include/linux/rcutiny.h b/include/linux/rcutiny.h > index ce9beec35e34..2e484aaa534f 100644 > --- a/include/linux/rcutiny.h > +++ b/include/linux/rcutiny.h > @@ -84,8 +84,8 @@ static inline void synchronize_sched_expedited(void) > synchronize_sched(); > } > > -static inline void kfree_call_rcu(struct rcu_head *head, > - rcu_callback_t func) > +static inline void kvfree_call_rcu(struct rcu_head *head, > + rcu_callback_t func) > { > call_rcu(head, func); > } From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752222AbeBFPGu (ORCPT ); Tue, 6 Feb 2018 10:06:50 -0500 Received: from mail-ve1eur01on0097.outbound.protection.outlook.com ([104.47.1.97]:33376 "EHLO EUR01-VE1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752037AbeBFPGl (ORCPT ); Tue, 6 Feb 2018 10:06:41 -0500 Subject: Re: [PATCH 1/2] rcu: Transform kfree_rcu() into kvfree_rcu() To: Steven Rostedt Cc: paulmck@linux.vnet.ibm.com, 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 References: <151791170164.5994.8253310844733420079.stgit@localhost.localdomain> <151791238553.5994.4933976056810745303.stgit@localhost.localdomain> <20180206093451.0de5ceeb@gandalf.local.home> From: Kirill Tkhai Message-ID: <52fe3917-cf72-d512-8422-d53bacf40113@virtuozzo.com> Date: Tue, 6 Feb 2018 18:06:33 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180206093451.0de5ceeb@gandalf.local.home> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [195.214.232.6] X-ClientProxiedBy: DB6PR1001CA0033.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:4:55::19) To AM5PR0801MB1332.eurprd08.prod.outlook.com (2603:10a6:203:1f::10) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 1be0ea72-f068-4eac-9d5b-08d56d733847 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(7020095)(4652020)(4534165)(7168020)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603307)(7153060)(7193020);SRVR:AM5PR0801MB1332; X-Microsoft-Exchange-Diagnostics: 1;AM5PR0801MB1332;3:Q2/WCQB9GipRiM/81IxZ4Miwflg3oxfZDhQ7e6154m4R6U9E7OjpWbDCRx5sjeXMJlRuKHnGDP/O73yLQIT+YWHzRWc/kaBsfpRCYzxrME4n/BY3ru4xxE0b4ePKYYhMqZnRQRo9KPEvhQpWzby3ME6b6iYUy+F41GxkNuOIHP7vW36XLNMzSlBSJySjh/OL7BrKgl+NgI6XDU26WtYeTJrsSoecrtk3ZivuiJ+xdnlMNUKZmflpaf7a8VuFxrf3;25:ZTZNHhTK/zdGmowiaJK2HFesxl/UPliEBrXoPM+13yYxu0mkhLUi9Z+xVhetyhdFneCCg+1INNpZRxgP/rrJNfSYO3+SoLzKT7JQCusAS5q9qQ2yw0jtuXB09htFeRX/xEljSQPrDANaCVa2yRzr8mUGzBqvBrxWQ4CFYbSAUPfLvZBXt2E/US5t4umvrZY59DrxYZnOAN1vHp4eMluE1oMfkaQqQB217lXcKeHyxZsBlyJ9aOnfzS7o4VvzTEETUALoQJ+Y51vSQU5u+gw/UjhfroIlBpr+wZ3Vgrpd3Ja5LkDhOFoPLK/srnun3SdA7BNLxDltIAuKBHiO5V/lzA==;31:ZmhRjUrTKRkk8he3BrzCVpkkq50Duy9qKD3OxOtk+ZmD4wF3Ul/CKlGywIIpGUB1ymG0CxCQ4YonXKs2At8BY5ljzzk92utXaq7BKvJDcNmbPBqfaKHtaOH5IJL42i3gn0elm1ykWXTk+XZ9b7VniL/yyXbEmFTVJ5xZ91Rn5+kvGw74Y+BWdn1WkvO45tVsU1CiJshg5RJyjFd3fFExpBL6jyD7SVmqJN6fzq0AuVU= X-MS-TrafficTypeDiagnostic: AM5PR0801MB1332: X-Microsoft-Exchange-Diagnostics: 1;AM5PR0801MB1332;20:XH1apU+qgF3CBWwaUzsDoc8SwSf4RRP93jRFoTe2gH///xMcGElRVFL+IIE4USIUkGurA+Yq4IUMvnJaNZdA0yPS0udMqC4JSay/IhxzxeTTNGbQI3rB1ZY02vQ95pFtwQ8OwngWtWxCojygZ6MLfOiJLz8CZ47WVTf2jZr65CvG3lJVOf0kU8nmlWdwTaeB/wmtxno8wmO8/QVFy/TS7o62xGW09x+HdmRjqzYu7XXs2VXfIwwpIJ+XiPntLBwJkDmDwqzqlxSrgtB02M3EwJP5CHab77L90nAJAd1VPrkvIBNA31vyz6qxghIQspDMa2FO+nYbe3/hBnlyVEYrJLJ+Q/qpnDqaUcJvGlXBDFDp4WVgVGibqYsebE6KBZiB3XNGiA0Um4xjYeQ/PP4YcUqc71IWLrgg3EOlkpHTzsw=;4:/2J1Yx9t1y2FmXfH73cgPa0mibewD9ICikBj2vd3JK3JiPKVB/WGcLT5t4TjrPnDTiUumiXSObXzMhUd/FZ1/eoTA2HH4ln1UkEhDZftEgzZf9VwN+M2z8QF/T1wo0QW7MpIix7I7gHWe3sb6MYuDrIQfL+W6nOx8NJX3rL4qfPKIMVN1RSekUfxZJqY1yInkfT5kJcpiwj6DIc8XZkTUqM5s3dJMy5gTTeBFM0UYS65TQEQ52lydgm32lPUgb/gptwlzFhRrCcUNZzsk1lJag== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040501)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231101)(2400082)(944501161)(3002001)(6041288)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(6072148)(201708071742011);SRVR:AM5PR0801MB1332;BCL:0;PCL:0;RULEID:;SRVR:AM5PR0801MB1332; X-Forefront-PRVS: 0575F81B58 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(6049001)(366004)(39380400002)(39840400004)(346002)(396003)(376002)(199004)(189003)(5660300001)(478600001)(65826007)(6666003)(2950100002)(86362001)(2906002)(105586002)(230700001)(52146003)(23676004)(6916009)(16576012)(58126008)(2486003)(76176011)(316002)(6116002)(3846002)(59450400001)(386003)(39060400002)(83506002)(52116002)(53546011)(186003)(77096007)(25786009)(16526019)(7736002)(66066001)(65956001)(65806001)(31686004)(47776003)(6486002)(305945005)(106356001)(55236004)(7416002)(4326008)(26005)(6346003)(8936002)(50466002)(81156014)(8676002)(36756003)(68736007)(81166006)(64126003)(229853002)(97736004)(53936002)(31696002)(6246003);DIR:OUT;SFP:1102;SCL:1;SRVR:AM5PR0801MB1332;H:[172.16.25.196];FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ktkhai@virtuozzo.com; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTTVQUjA4MDFNQjEzMzI7MjM6VVRvY2RNNU5JWElxM1pUbWliMVZrSEN3?= =?utf-8?B?ci9GdmZyY1pRak1ITWQ0MSszUWVrVndvQzIwZHNUZ0NOazlST3p2MWZwREVr?= =?utf-8?B?cGJsWTdKS2l3UjJIU1hDaGpiVkN0QkVJZlByT3BQSmI3VkdIS2NkUzVKdU5O?= =?utf-8?B?WjlINm81dnN5enpkTWNiYm8xM1FFWSs0RVdYaFJSOWc1TExKeHVZQUkyVG9R?= =?utf-8?B?WEQzZXRZSzRzODB1dWJrNFNmWHMvbXBwS0JNMWtKcmk4Y1Bab0NkOGpoV2dt?= =?utf-8?B?bkR4V01wNDZhdEgyOUlDUkJOMXJxWW1YdVVLWU8zMVNlRkJkdXIxODhZQkpP?= =?utf-8?B?bms1R1A2ejNsUTRPanE2S2tHNkhYMlJsdWIvMGVraFNMQllhTi9vTVhxWjc5?= =?utf-8?B?bkkzVm1yU0oySnhpbTNJdm9mV3N2NnBxODEzaFhaWjcrcVN4T3FxbU42UnVs?= =?utf-8?B?QjI4a1BBYVR1S3RHVERSVjZZWUg2MnpVZXRyOGZiZy9PeVdHcHNRRW91WGVs?= =?utf-8?B?bG0vRXhFOWFPRm14a1Z0NWIzbW9FVEJpN01EZXBNeUhRQlRMeFhzdG5mOUht?= =?utf-8?B?TWErcy9ub25VVU1wa1BsY1BVZW5LU011dGJ0WWlpL0xBSTk1TXFqYTV4a2ZQ?= =?utf-8?B?STY1M0tuVnhMSGRmSiszTTFKNDhUdTBsY3Roa2E5RUtnMlhueGVwekVLaFFJ?= =?utf-8?B?dzMwdE9HWW1OeFVCVmtGVmdiR2ZpNUgyZGpQY2JtZ2ZmM3RUTzVxQ1AxVkNT?= =?utf-8?B?RGZEVkVnaWJGU2dlV21sT2dLdndSaEgrSXF2d1F5RFBBQ1pnYkVJRkxRMEZx?= =?utf-8?B?M3RxT1dHdnpKUVdxbjFwK0RxZlZ2NHJ2RE9LRVRqOXFlbGREaCtwQVlleDdI?= =?utf-8?B?TjBwSTI3V1Q0cFlWQlVPZTc4c1JURVNKLzFQa20rUkVsRVZockhBaG9CNzUz?= =?utf-8?B?SzROcU5kY1ZZd1FKMS9zbTdUYy9RNGExbTZCNEhGcDVmcTlObHZIQlRwTmds?= =?utf-8?B?UlRxRkxhOHE3ZGk5aXFTUC9GZFVJZzNnNEtRTVQrOXQzSGl2VVJtd1NaZE5B?= =?utf-8?B?bUxiYWFhWmszMXcyU0ZkUlF1SHFKS0NXUzByMHFPMDNhK3hiRnZoU0g1UTdX?= =?utf-8?B?MmV3TnJ2Q0k5L0grTkorRGNEbnBjRmkvUjF4SmZQT2pCaE9nYXM0QVB6YlN4?= =?utf-8?B?cG1uck5ENTJmTEx2anIraUJyQlFsZWZncXpNTVB6bGxubElHbW9JWVE0RUVz?= =?utf-8?B?U0s5bnNkU3ZHQ2MwVVhQaFBJMjdHbVFRZUYvV3QwYktnc1J0QTlLUEFMS0t1?= =?utf-8?B?YmR1aC9hcmhqU09WbjJmRjRXWG4rd3FsUk80eGdXSWVCdEdmeUhTZi9zZVFD?= =?utf-8?B?TW9iWUUrQ1hRZ01TdXlrSitCQmN3Q3E2MU0rakJSdEtzS0VFWkd2YVhTK1Rm?= =?utf-8?B?bGk2ZjdWN3AxalVyQkY1Uy83dUJUR3JENEJwZG5pc0Rlc3o5dWVvMlB5QmVY?= =?utf-8?B?TDhqZlU4Q2ovZWNKTUpoTWFncVJ5RzJsV3BOcnprdXBRZzVxT0JXT29PVzUw?= =?utf-8?B?R1h5dXQwVE8xeUl0WFBoejd6eXd5di90QXg5RDRML3pjYjdXa216a1Q2NkxH?= =?utf-8?B?Y0JZbnpxL3IrWk84UHVPMFhpSEV5RGIwMVBaSzRjZ2lxb3JVYStENUVtWjlW?= =?utf-8?B?ZUVVSU1pc05WSGxCcHdzSXc0V2RXM0dBUlpTOTJVTHg1NjEyZDdBQjhvd1RE?= =?utf-8?B?TkdoNUJDYlZBbktVOGFVenNyaUd5VzU5OWNkd0FKcXBTT1V4azN5RTZmajBO?= =?utf-8?B?TGlWSit4bEs0MzZGMHhnanNkOE9YSDNXTEhLV05vcFgySnNyMTl2Y2FQenIy?= =?utf-8?B?ZTRqd2JCUnZDUkZjeS93bmNXOUZTSGljaXgzdmJrb0k0czBDaDlnVXJQelps?= =?utf-8?B?L2VXZVRlU3hVS1JhMW5hanNTTmFJTVJFeVFuYlVYWHVHZStZSGowQ0paV2pu?= =?utf-8?Q?H/btmb0H?= X-Microsoft-Exchange-Diagnostics: 1;AM5PR0801MB1332;6:npNlMD4/NYSraHMTBQPIQbpADlVxXsDuZhLQqMEi0aYriby7EmJ3aJ7GYkJVbxbD8CCfmlI5oqudzkHaXHXT8lyh3tYX/tvOKykQXJuqznooq4p1IITN3hMGK3cEbTBZqKso/1nZFSuEsq5hNalr6jPYTpevnOM/3KE+TpUisF/W52rvSRm6EMSSaAUIGiqaMT++cbRU6sEl3XvQj0cbFbANj00X/s2SZK6/WH0xag65lLgR7+PaiCeGTSaySSTdxvWhwfGaPP6ECtv2dMkhhoMNgQp17F9DpLeu2jb75ljfrCI/NxVkyOug9yEP5oqVBSVQui8swCGsdNFJnherFHH9QEXsqG+DNwyMzhLen5U=;5:sUIsL7v45TjEaTExczaGoN8n9p36KHQGmRfb7F3yv6HrvAE60c2QFqLh33S5dsLcRM4T4y/jBfEx614YyhS6qfT1BOA0oOROwuCMzewt/Q+uDCvaq6dDlp4J35aGr8F1kF9CpOmzb+8VKWr+n2pgh4SxUO8Yyrv9SqbrO9vHCo8=;24:blVChFu1NGlfu36G71kL4bWoxwVXN+KjQOvrUHIB0Gov/gj9U/fUgw0qIO5MEFNdAdrm3V1s+7kCOAtTWV5pCQVRu0QzCaimj1SqS7wNYPI=;7:AdGBvBWIJF6YD65Co0ppo0dFe3JgnDAOqmQqwd+K15emU2PqRyAF9sJ3BXJTqhwxMQV1p5u67WjxGnA6c96GsAVbUpyKQAU7CMaImsYJ5n9NT8eb+tS1FZ0TkDXVmIaHAf1vCQu5vgtRyC0MMjYTaJzOtQeZzVtXD9EXWdatub+ydIXV0c5XMVkWcJxrsyWymkoLLLHbTg9rSTNC/CQU8oVtb22MQz5njxB9gDFxM2Drs4vyJ647FiSr5B+inzXw SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;AM5PR0801MB1332;20:I+MjxkOp9WMW8tMNsUQ9G3UtzMDZmY7gyNE63nCRcoeWlh8CQB2Mlc9f/wRwAmeHCgm+vZxZoTWqj4GXcy4WhCppw9g3ftUXUOPy4edl5Lu0sv6SJ+qvotkz3NzNNXIueObRDbc1kntK/RX032AoTVcNQ61inwtvEM7iAsoJGu4= X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Feb 2018 15:06:36.2864 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 1be0ea72-f068-4eac-9d5b-08d56d733847 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0801MB1332 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06.02.2018 17:34, Steven Rostedt wrote: > On Tue, 06 Feb 2018 13:19:45 +0300 > Kirill Tkhai wrote: > >> /** >> - * kfree_rcu() - kfree an object after a grace period. >> - * @ptr: pointer to kfree >> + * kvfree_rcu() - kvfree an object after a grace period. >> + * @ptr: pointer to kvfree >> * @rcu_head: the name of the struct rcu_head within the type of @ptr. >> * > > You may want to add a big comment here that states this works for both > free vmalloc and kmalloc data. Because if I saw this, I would think it > only works for vmalloc, and start implementing a custom one for kmalloc > data. There are kfree_rcu() and vfree_rcu() defined below, and they will give compilation error if someone tries to implement one more primitive with the same name. We may add a comment, but I'm not sure it will be good if people will use unpaired brackets like: obj = kmalloc(..) kvfree_rcu(obj,..) after they read such a commentary that it works for both vmalloc and kmalloc. After this unpaired behavior distribute over the kernel, we won't be able to implement some debug on top of this defines (I'm not sure it will be really need in the future, but anyway). Though, we may add a comment forcing use of paired bracket. Something like: /** * kvfree_rcu() - kvfree an object after a grace period. This is a primitive for objects allocated via kvmalloc*() family primitives. Do not use it to free kmalloc() and vmalloc() allocated objects, use kfree_rcu() and vfree_rcu() wrappers instead. How are you about this? Kirill >> - * Many rcu callbacks functions just call kfree() on the base structure. >> + * Many rcu callbacks functions just call kvfree() on the base structure. >> * These functions are trivial, but their size adds up, and furthermore >> * when they are used in a kernel module, that module must invoke the >> * high-latency rcu_barrier() function at module-unload time. >> * >> - * The kfree_rcu() function handles this issue. Rather than encoding a >> - * function address in the embedded rcu_head structure, kfree_rcu() instead >> + * The kvfree_rcu() function handles this issue. Rather than encoding a >> + * function address in the embedded rcu_head structure, kvfree_rcu() instead >> * encodes the offset of the rcu_head structure within the base structure. >> * Because the functions are not allowed in the low-order 4096 bytes of >> * kernel virtual memory, offsets up to 4095 bytes can be accommodated. >> * If the offset is larger than 4095 bytes, a compile-time error will >> - * be generated in __kfree_rcu(). If this error is triggered, you can >> + * be generated in __kvfree_rcu(). If this error is triggered, you can >> * either fall back to use of call_rcu() or rearrange the structure to >> * position the rcu_head structure into the first 4096 bytes. >> * >> @@ -871,9 +871,12 @@ static inline notrace void rcu_read_unlock_sched_notrace(void) >> * The BUILD_BUG_ON check must not involve any function calls, hence the >> * checks are done in macros here. >> */ >> -#define kfree_rcu(ptr, rcu_head) \ >> - __kfree_rcu(&((ptr)->rcu_head), offsetof(typeof(*(ptr)), rcu_head)) >> +#define kvfree_rcu(ptr, rcu_head) \ >> + __kvfree_rcu(&((ptr)->rcu_head), offsetof(typeof(*(ptr)), rcu_head)) >> >> +#define kfree_rcu(ptr, rcu_head) kvfree_rcu(ptr, rcu_head) >> + >> +#define vfree_rcu(ptr, rcu_head) kvfree_rcu(ptr, rcu_head) >> >> /* >> * Place this after a lock-acquisition primitive to guarantee that >> diff --git a/include/linux/rcutiny.h b/include/linux/rcutiny.h >> index ce9beec35e34..2e484aaa534f 100644 >> --- a/include/linux/rcutiny.h >> +++ b/include/linux/rcutiny.h >> @@ -84,8 +84,8 @@ static inline void synchronize_sched_expedited(void) >> synchronize_sched(); >> } >> >> -static inline void kfree_call_rcu(struct rcu_head *head, >> - rcu_callback_t func) >> +static inline void kvfree_call_rcu(struct rcu_head *head, >> + rcu_callback_t func) >> { >> call_rcu(head, func); >> } From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752383AbeBFPta (ORCPT ); Tue, 6 Feb 2018 10:49:30 -0500 Received: from mail.kernel.org ([198.145.29.99]:54620 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751424AbeBFPtW (ORCPT ); Tue, 6 Feb 2018 10:49:22 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E8B2E21748 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=goodmis.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=rostedt@goodmis.org Date: Tue, 6 Feb 2018 10:49:19 -0500 From: Steven Rostedt To: Kirill Tkhai Cc: paulmck@linux.vnet.ibm.com, 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 Subject: Re: [PATCH 1/2] rcu: Transform kfree_rcu() into kvfree_rcu() Message-ID: <20180206104919.0bc1734d@gandalf.local.home> In-Reply-To: <52fe3917-cf72-d512-8422-d53bacf40113@virtuozzo.com> References: <151791170164.5994.8253310844733420079.stgit@localhost.localdomain> <151791238553.5994.4933976056810745303.stgit@localhost.localdomain> <20180206093451.0de5ceeb@gandalf.local.home> <52fe3917-cf72-d512-8422-d53bacf40113@virtuozzo.com> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 6 Feb 2018 18:06:33 +0300 Kirill Tkhai wrote: > There are kfree_rcu() and vfree_rcu() defined below, and they will give > compilation error if someone tries to implement one more primitive with > the same name. Ah, I misread the patch. I was thinking you were simply replacing kfree_rcu() with kvfree_rcu(), but now see the macros added below it. > > We may add a comment, but I'm not sure it will be good if people will use > unpaired brackets like: > > obj = kmalloc(..) > kvfree_rcu(obj,..) > > after they read such a commentary that it works for both vmalloc and kmalloc. > After this unpaired behavior distribute over the kernel, we won't be able > to implement some debug on top of this defines (I'm not sure it will be really > need in the future, but anyway). > > Though, we may add a comment forcing use of paired bracket. Something like: > > /** > * kvfree_rcu() - kvfree an object after a grace period. > This is a primitive for objects allocated via kvmalloc*() family primitives. > Do not use it to free kmalloc() and vmalloc() allocated objects, use kfree_rcu() > and vfree_rcu() wrappers instead. > > How are you about this? Never mind, I missed the adding of kfree_rcu() at the bottom, and was thinking that we were just using kvfree_rcu() for everything. That's what I get for looking at patches before my first cup of coffee ;-) If you want to add a comment, feel free, but taking a second look, I don't feel it is necessary. -- Steve From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753253AbeBGCRA (ORCPT ); Tue, 6 Feb 2018 21:17:00 -0500 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:46132 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752859AbeBGCQ7 (ORCPT ); Tue, 6 Feb 2018 21:16:59 -0500 Date: Tue, 6 Feb 2018 18:17:03 -0800 From: "Paul E. McKenney" To: Kirill Tkhai Cc: josh@joshtriplett.org, rostedt@goodmis.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, brouer@redhat.com, rao.shoaib@oracle.com Subject: Re: [PATCH 0/2] rcu: Transform kfree_rcu() into kvfree_rcu() Reply-To: paulmck@linux.vnet.ibm.com References: <151791170164.5994.8253310844733420079.stgit@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <151791170164.5994.8253310844733420079.stgit@localhost.localdomain> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 x-cbid: 18020702-0056-0000-0000-00000416B8A7 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00008488; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000248; SDB=6.00986026; UDB=6.00500366; IPR=6.00765393; BA=6.00005813; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00019412; XFM=3.00000015; UTC=2018-02-07 02:16:56 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18020702-0057-0000-0000-0000084E27CE Message-Id: <20180207021703.GC3617@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-02-07_01:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1802070022 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 06, 2018 at 01:19:29PM +0300, Kirill Tkhai wrote: > Recent times kvmalloc() begun widely be used in kernel. > Some of such memory allocations have to be freed after > rcu grace period, and this patchset introduces a generic > primitive for doing this. > > Actually, everything is made in [1/2]. Patch [2/2] is just > added to make new kvfree_rcu() have the first user. > > The patch [1/2] transforms kfree_rcu(), its sub definitions > and its sub functions into kvfree_rcu() form. The most > significant change is in __rcu_reclaim(), where kvfree() > is used instead of kfree(). Since kvfree() is able to > have a deal with memory allocated via kmalloc(), vmalloc() > and kvmalloc(); kfree_rcu() and vfree_rcu() may simply > be defined through this new kvfree_rcu(). Interesting. So it is OK to kvmalloc() something and pass it to either kfree() or kvfree(), and it had better be OK to kvmalloc() something and pass it to kvfree(). Is it OK to kmalloc() something and pass it to kvfree()? If so, is it really useful to have two different names here, that is, both kfree_rcu() and kvfree_rcu()? Also adding Jesper and Rao on CC for their awareness. Thanx, Paul > --- > > Kirill Tkhai (2): > rcu: Transform kfree_rcu() into kvfree_rcu() > mm: Use kvfree_rcu() in update_memcg_params() > > > include/linux/rcupdate.h | 31 +++++++++++++++++-------------- > include/linux/rcutiny.h | 4 ++-- > include/linux/rcutree.h | 2 +- > include/trace/events/rcu.h | 12 ++++++------ > kernel/rcu/rcu.h | 8 ++++---- > kernel/rcu/tree.c | 14 +++++++------- > kernel/rcu/tree_plugin.h | 10 +++++----- > mm/slab_common.c | 10 +--------- > 8 files changed, 43 insertions(+), 48 deletions(-) > > -- > Signed-off-by: Kirill Tkhai > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752992AbeBGEXt (ORCPT ); Tue, 6 Feb 2018 23:23:49 -0500 Received: from bombadil.infradead.org ([65.50.211.133]:59357 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752465AbeBGEXr (ORCPT ); Tue, 6 Feb 2018 23:23:47 -0500 Date: Tue, 6 Feb 2018 20:23:34 -0800 From: Matthew Wilcox To: "Paul E. McKenney" Cc: Kirill Tkhai , josh@joshtriplett.org, rostedt@goodmis.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, brouer@redhat.com, rao.shoaib@oracle.com Subject: Re: [PATCH 0/2] rcu: Transform kfree_rcu() into kvfree_rcu() Message-ID: <20180207042334.GA16175@bombadil.infradead.org> References: <151791170164.5994.8253310844733420079.stgit@localhost.localdomain> <20180207021703.GC3617@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180207021703.GC3617@linux.vnet.ibm.com> User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 06, 2018 at 06:17:03PM -0800, Paul E. McKenney wrote: > So it is OK to kvmalloc() something and pass it to either kfree() or > kvfree(), and it had better be OK to kvmalloc() something and pass it > to kvfree(). > > Is it OK to kmalloc() something and pass it to kvfree()? Yes, it absolutely is. void kvfree(const void *addr) { if (is_vmalloc_addr(addr)) vfree(addr); else kfree(addr); } > If so, is it really useful to have two different names here, that is, > both kfree_rcu() and kvfree_rcu()? I think it's handy to have all three of kvfree_rcu(), kfree_rcu() and vfree_rcu() available in the API for the symmetry of calling kmalloc() / kfree_rcu(). Personally, I would like us to rename kvfree() to just free(), and have malloc(x) be an alias to kvmalloc(x, GFP_KERNEL), but I haven't won that fight yet. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752992AbeBGFB6 (ORCPT ); Wed, 7 Feb 2018 00:01:58 -0500 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:45800 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750745AbeBGFB4 (ORCPT ); Wed, 7 Feb 2018 00:01:56 -0500 Date: Tue, 6 Feb 2018 21:02:00 -0800 From: "Paul E. McKenney" To: Matthew Wilcox Cc: Kirill Tkhai , josh@joshtriplett.org, rostedt@goodmis.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, brouer@redhat.com, rao.shoaib@oracle.com Subject: Re: [PATCH 0/2] rcu: Transform kfree_rcu() into kvfree_rcu() Reply-To: paulmck@linux.vnet.ibm.com References: <151791170164.5994.8253310844733420079.stgit@localhost.localdomain> <20180207021703.GC3617@linux.vnet.ibm.com> <20180207042334.GA16175@bombadil.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180207042334.GA16175@bombadil.infradead.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 x-cbid: 18020705-0024-0000-0000-0000031FD3BD X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00008488; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000248; SDB=6.00986081; UDB=6.00500399; IPR=6.00765448; BA=6.00005813; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00019415; XFM=3.00000015; UTC=2018-02-07 05:01:54 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18020705-0025-0000-0000-000046E5FD2C Message-Id: <20180207050200.GH3617@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-02-07_01:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1802070061 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 06, 2018 at 08:23:34PM -0800, Matthew Wilcox wrote: > On Tue, Feb 06, 2018 at 06:17:03PM -0800, Paul E. McKenney wrote: > > So it is OK to kvmalloc() something and pass it to either kfree() or > > kvfree(), and it had better be OK to kvmalloc() something and pass it > > to kvfree(). > > > > Is it OK to kmalloc() something and pass it to kvfree()? > > Yes, it absolutely is. > > void kvfree(const void *addr) > { > if (is_vmalloc_addr(addr)) > vfree(addr); > else > kfree(addr); > } > > > If so, is it really useful to have two different names here, that is, > > both kfree_rcu() and kvfree_rcu()? > > I think it's handy to have all three of kvfree_rcu(), kfree_rcu() and > vfree_rcu() available in the API for the symmetry of calling kmalloc() > / kfree_rcu(). > > Personally, I would like us to rename kvfree() to just free(), and have > malloc(x) be an alias to kvmalloc(x, GFP_KERNEL), but I haven't won that > fight yet. But why not just have the existing kfree_rcu() API cover both kmalloc() and kvmalloc()? Perhaps I am not in the right forums, but I am not hearing anyone arguing that the RCU API has too few members. ;-) Thanx, Paul From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753370AbeBGHyV (ORCPT ); Wed, 7 Feb 2018 02:54:21 -0500 Received: from relay3-d.mail.gandi.net ([217.70.183.195]:49661 "EHLO relay3-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750815AbeBGHyU (ORCPT ); Wed, 7 Feb 2018 02:54:20 -0500 X-Originating-IP: 50.39.166.153 Date: Tue, 6 Feb 2018 23:54:09 -0800 From: Josh Triplett To: "Paul E. McKenney" Cc: Matthew Wilcox , Kirill Tkhai , rostedt@goodmis.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, brouer@redhat.com, rao.shoaib@oracle.com Subject: Re: [PATCH 0/2] rcu: Transform kfree_rcu() into kvfree_rcu() Message-ID: <20180207075409.GA5726@localhost> References: <151791170164.5994.8253310844733420079.stgit@localhost.localdomain> <20180207021703.GC3617@linux.vnet.ibm.com> <20180207042334.GA16175@bombadil.infradead.org> <20180207050200.GH3617@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180207050200.GH3617@linux.vnet.ibm.com> User-Agent: Mutt/1.9.3 (2018-01-21) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 06, 2018 at 09:02:00PM -0800, Paul E. McKenney wrote: > On Tue, Feb 06, 2018 at 08:23:34PM -0800, Matthew Wilcox wrote: > > On Tue, Feb 06, 2018 at 06:17:03PM -0800, Paul E. McKenney wrote: > > > So it is OK to kvmalloc() something and pass it to either kfree() or > > > kvfree(), and it had better be OK to kvmalloc() something and pass it > > > to kvfree(). > > > > > > Is it OK to kmalloc() something and pass it to kvfree()? > > > > Yes, it absolutely is. > > > > void kvfree(const void *addr) > > { > > if (is_vmalloc_addr(addr)) > > vfree(addr); > > else > > kfree(addr); > > } > > > > > If so, is it really useful to have two different names here, that is, > > > both kfree_rcu() and kvfree_rcu()? > > > > I think it's handy to have all three of kvfree_rcu(), kfree_rcu() and > > vfree_rcu() available in the API for the symmetry of calling kmalloc() > > / kfree_rcu(). > > > > Personally, I would like us to rename kvfree() to just free(), and have > > malloc(x) be an alias to kvmalloc(x, GFP_KERNEL), but I haven't won that > > fight yet. > > But why not just have the existing kfree_rcu() API cover both kmalloc() > and kvmalloc()? Perhaps I am not in the right forums, but I am not hearing > anyone arguing that the RCU API has too few members. ;-) I don't have any problem with having just `kvfree_rcu`, but having just `kfree_rcu` seems confusingly asymmetric. (Also, count me in favor of having just one "free" function, too.) From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753419AbeBGH5j (ORCPT ); Wed, 7 Feb 2018 02:57:39 -0500 Received: from mail-ve1eur01on0116.outbound.protection.outlook.com ([104.47.1.116]:42144 "EHLO EUR01-VE1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750815AbeBGH5h (ORCPT ); Wed, 7 Feb 2018 02:57:37 -0500 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ktkhai@virtuozzo.com; Subject: Re: [PATCH 0/2] rcu: Transform kfree_rcu() into kvfree_rcu() To: paulmck@linux.vnet.ibm.com, Matthew Wilcox Cc: josh@joshtriplett.org, rostedt@goodmis.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, brouer@redhat.com, rao.shoaib@oracle.com References: <151791170164.5994.8253310844733420079.stgit@localhost.localdomain> <20180207021703.GC3617@linux.vnet.ibm.com> <20180207042334.GA16175@bombadil.infradead.org> <20180207050200.GH3617@linux.vnet.ibm.com> From: Kirill Tkhai Message-ID: Date: Wed, 7 Feb 2018 10:57:28 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180207050200.GH3617@linux.vnet.ibm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [195.214.232.6] X-ClientProxiedBy: HE1P189CA0022.EURP189.PROD.OUTLOOK.COM (2603:10a6:7:53::35) To HE1PR0801MB1338.eurprd08.prod.outlook.com (2603:10a6:3:39::28) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: d71ddee2-bf82-4d3e-ccff-08d56e00729b X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(7020095)(4652020)(4534165)(7168020)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603307)(7153060)(7193020);SRVR:HE1PR0801MB1338; X-Microsoft-Exchange-Diagnostics: 1;HE1PR0801MB1338;3:qq1ex+4xKfPY3pzcC9TE1/Hy5zpjr+Lt80lgo2hVgnrypoDuVf06dig1h4nQp7nZ0pA2tc1O1YZZlKVd/Y3FhHn1Xm1Zxlu2Z2msB899prW9oKtVIgcbiH0IjqneHPYsALqQd2Mu/ZSTazZ35IebEHa3FqJ0XrZM/aCZLZatmp3R5IDjOLvf7FkLxdemUuEMrPut39pvMzt1YtOI+rMHQBNx5cbaENiXBPlV3gYxvaRXfP8PSgV8xX8A6UYMFAF9;25:KbDxcjW7pqPCEZIh1LM5kXLYbMEg9pJ/jo5Nhf+imp68vREa8TmrCZOnlnobKT9QkMUbAnCd4/BIwNkLZtSKsUDrtRrNih95able51/xwfla8nBxSVNsJ4E6Bl2wBoIiahp9oPS4JPzpKMyBFGwO7/YLexfRy2wZIU5Tv3eHBRNNnwi7QKUQdPhpub1GrROoF7qAgSfAGwbJLbIaZWPQuwmz6nwE04vRxJ4zZBlSSmU2TRpEJ+esW2YhY3fWLg4hfFLi7T9yPbY3FtU2ITgIc4kFERRxbj3PyOBsMwhEYnYK3lXAZp+lgRNsO++t3oQUNjX77gSOPt/nis27GUPpTA==;31:QVXoyXcY7Q4t5EvgiQnQCa6AFb+CD5AOm95VP5pY21u0ophV4cy9bUoOfyylljsurs4PQgSHW5bYC0anYBEEE+xBd8XN/aYdp4ifsUXTb/xUoPa8YclLLoR+cMEY0aDtuHWYEF+SZhB+mPuXogTcyAgAznF+JKqjAZnuBY71ZCMq0RDo/En5VSBCdsXGnt3PVPM/Lp9jFhpgBpccRMUgMCZmpX3MAKYbSA/27hlz4tk= X-MS-TrafficTypeDiagnostic: HE1PR0801MB1338: X-Microsoft-Exchange-Diagnostics: 1;HE1PR0801MB1338;20:HrVtVDu0zyx//XyNIcDe0Fc4VfJ6ftT7k7iJg2w8mG1aRH/Gg8L38P9zDEyeQVgZJ/F2K71CDf3R8O0hhNyKg/6NaZIHcysO09CyagVEWirJCEyFua/JgTDdyBauOS1J7VlCezTtybR51tt62+pVkmdnFznO4y++v+HaQSWforuPHGSv3D4kw5QETVi6Xf8Zzmr7rv9cR5JxhjP8wxmXaE/UoPMgPumy3Vh4RRQdUE4aLdQ85A79Ca3dY0YXCvVpX8lpDKSfzwtv1Rfz7gCmjFgSzXbKOchKAmBv3oM9CwgxhchI7WfSlIeZMO8i9iSXSmYTAUc46U7pD26mJs6B3W4TOQoRCaCHTeVHjUMXwioTXxIdi4U3VO1UKEPGLcyny5G+OVFOs3kjzQlgs/KM4C1uAhOlcXHm9vRBcHKUUEo=;4:5/eYqs2XlgwC7B0xkXOED6KcBVJ8pXYZNJBXCBd1VQEtCnmpCiazNLODKZOsLEHZXTV4h6Qj35a6jdKH9tjzeOIr89PnuBpSIL0RfaYrBuOZRx2ns6PXmkrvLyeaLtJYqUizy9tbJFzUvzdeTOyT3tlVGvlTAucVjwjajrVXSMxtt7X9Jtc+FcRQFZ1tc6k+DZsk80WuxQkgNhAduy6q6rJYBvn8lzxpzmY//emakk6w5ZgafiR+qHsczpntl1oUlh3P4kfNS0ILSw4B1SMEHA== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040501)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(3231101)(2400082)(944501161)(6041288)(20161123562045)(20161123558120)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011);SRVR:HE1PR0801MB1338;BCL:0;PCL:0;RULEID:;SRVR:HE1PR0801MB1338; X-Forefront-PRVS: 0576145E86 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(6049001)(39380400002)(376002)(346002)(39850400004)(396003)(366004)(199004)(189003)(65956001)(66066001)(16526019)(4326008)(2950100002)(6666003)(6916009)(64126003)(6486002)(93886005)(25786009)(186003)(6246003)(50466002)(97736004)(86362001)(229853002)(81166006)(31696002)(36756003)(230700001)(8936002)(68736007)(105586002)(53936002)(39060400002)(478600001)(7736002)(106356001)(7416002)(55236004)(76176011)(53546011)(316002)(52116002)(26005)(8676002)(386003)(2486003)(52146003)(23676004)(77096007)(58126008)(16576012)(5660300001)(81156014)(47776003)(65826007)(65806001)(3846002)(6116002)(305945005)(2906002)(31686004)(83506002);DIR:OUT;SFP:1102;SCL:1;SRVR:HE1PR0801MB1338;H:[172.16.25.196];FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtIRTFQUjA4MDFNQjEzMzg7MjM6YTR5R0Q3c2IvYzhEeWp6R3JHRXI1bjFt?= =?utf-8?B?ZVhhTUdkdW5xWHRsMmQvcDFFTGI2V3lEb0ZpZGdMN25vdTl1bEliN1VHM1Ex?= =?utf-8?B?RFJVZExUR0pFai9zd2lOczd0US9Ed3VtVTE0SmlYcnVzcFkzUkFUZGEweTVG?= =?utf-8?B?c1FLZlJqeTBSNjNPWFNrTXZvOTlDT3BDNXVXcklOaG1kMnpzU3Ntck0reEFS?= =?utf-8?B?SkVZRUZQT2hSNG44MllHUXpzYXlLQy9HdzViNStwUE5Pb3F6d1B2TENyalRO?= =?utf-8?B?QVVwU3NRLy9XeEhub1k3VTh5KzhnNFo1TDdkQVdGT2pYUG9VNU5GM3paOU1s?= =?utf-8?B?VjU4YXZtRTRkaThSZ0tNQ3JCN3Z4OXlTbFRPbGVMbDltSXFER3NQNStaaFhQ?= =?utf-8?B?UnQ4bjVWYTA0bmhqQWY4MzdZTEVFcGNjaFhMcFp2ZUhWZ0g4bkdrRmZSWU9v?= =?utf-8?B?Z20xTC9mUHRlODE3WWs2TThhWkxoZHlqcmNvM2ZhTGpjTHJiN3RWT25yT0hs?= =?utf-8?B?anJ4STBoR3kxWHo1Tk95T2gzd0tLbHg3cjd0NERGdzB3aFJ5TU1PTC96K2ps?= =?utf-8?B?QURWM0pRZkNDRHVzbnlsYjVZeGVDTHJxN3VKbFg0bnliS2J2YVdpNk5SWVFx?= =?utf-8?B?Sk9zMXFUSis1Rk9ta1JjRGYrTjJxbG43b0VMcWlnbDhvZysxVXZlN2tFNnpa?= =?utf-8?B?UGFpZnlKcVN1QXNtZTZIam9GK1FEYURiNVNJVzJGNWVrSTlpcWp5VTlNbTJE?= =?utf-8?B?T3N0Z040a1dFcEpQY29ER1N4dW9URndQK3FUQ2FFZWU3UWZ1SlNXQTIxVnJ2?= =?utf-8?B?eGxiWXppWHBDV3pwR05UY0VQWEZzSEFBMlZQZUExUkVQZVR6cWI5Qjc4cExL?= =?utf-8?B?Nk9lOHNLQVRMeWgzY0tPQUgwTWFqNXBVaGVOaVV4WXhyUFhCZXNIMUtVeTg2?= =?utf-8?B?ZFo2KzhqN2NjUUk0L0xnUG5GRFVMQmVRYklnK0VQWlpSTm9TMVVwM05sMGpw?= =?utf-8?B?dStEa3g0QjhOUHNkdnEwZXdBTllnRUI0MVh1UWRPYWpZUUEyWi9IV3JMWnVQ?= =?utf-8?B?RFUzTi9OMEtKeGErZVpIaXVpdUNNVjNmZi9LQ3FwWThTcmJtYk84SXRWVUhx?= =?utf-8?B?KzBZY3l5dXFONUNqY3pkYlZkdHRxU1hLQ1ludS92U0hhN3l4bUZlYUUvdVh0?= =?utf-8?B?RjduczYzZ1lSN2IxdjJqaHQwQ201cXBiZ3QwNnU4a0F0V1hITjM5RHc2L1pi?= =?utf-8?B?YWpvWVJNYjFuSFZBaDJPZHMvbG5jeUxBUlN4RGVHN3hCb1l1SDJOdVh1TW42?= =?utf-8?B?V1hINUtJb1huTnl5WEhNbSsyV3NubFBZWlRHckRvZEtmOWpzWS9tazk0WVZn?= =?utf-8?B?RzMrUTB6RUxKbnZCK0tsRThGWjhvTk8xNkt6VUdPTzBvdEp6UGsrL2NDeFVu?= =?utf-8?B?VVdPVG0vUzNiR0ZqTURQWC9IOXpIOVRwd2pEdVRIQlR2V0RhTzNDUlNSQUt5?= =?utf-8?B?OXlWWEhOdG9pdGVoRS9nL3NuSnV6dE0wUS9jZnpHZEViVGN6em1Ja3RxZWdO?= =?utf-8?B?RGFoU1FkZHYzWEYzZ2kxOWNkVEV0bkZaSHVLUmRJV09wU0NlVnV6aFhOZ0gr?= =?utf-8?B?QkpHcDBQMkE3OWRZQnF5VW9YTXY1aDBDajl0UEZZVllubUQxRVNrcGNXSlpK?= =?utf-8?B?MXB1Y29Cdm5KTjlDaUhjblA0eHVlYS8yaTJSVFVYSGNhd0lSUXlLNU92dDBY?= =?utf-8?B?blV4U1QrN2JiTEpQVkI1RHFsOHhNc3ZHZTlGcnQ1RGFGbVJwbG0rRE9CRkw0?= =?utf-8?B?VEdTc2U1UGFtZnpRbzdyYWo2NEJCaEdQVUY3bDQ1MWlPU2M4Y1ZJbEcxdXRK?= =?utf-8?B?S09OOXFaamFaTTdtd1JaQlR1TzJxci9CUXcwOEVhTmQzQU5YMklTTllGRVhI?= =?utf-8?Q?vyS1/y/HATVuidzT6GUEqUJn17OB5al4=3D?= X-Microsoft-Exchange-Diagnostics: 1;HE1PR0801MB1338;6:8scAZAhZNJJ+J9Qy05cx3n8qXv/QL+eN5QaMR7ZhpSKBGLMQB8ukk2QGynj7wWP0icQmyUzGwxyOWcul7g1w+zCHUTn4i1GMuSffJo2gbKKtK5WtAiVMNnm0czWj8QH6XYR+GqZuJiaCtoApO98hc5X15xX8/m91G86UR4JY3V/ZuVCgfY4mg/v0bz8uGIYRi4pGZeuBCs8mziYnsMAqRqrLcmnzrkHspLTTiKFgh9TlrxDVrScRkRMnnysz9tCj3OwT6ctCg60K1irmj/jx2NiK76DLjloD2iJsur41hyPAvQ9TC3+EolfE0ZlyhUrMLi6AY4x9MX9QQfWIAkzTM6PHf+qET1ewcbgKx8DkaJE=;5:+q38wcEKjZdFf2TC1/YfMY82P15gHn8NKKnEbNTeahQuL7JfI9DeKH6WTM8uhZz9Z9U0JZpNMl5h8JMrf4jaOV4XPZ7olOl7uMwxbVk4r7/JpZqWLdqWXcPQFYkId3aFm+kq7r5XArY/14mkD6vWBblSqpolWF49yoNtlDmJQTk=;24:YIOEaiAJpPQxdGz8OyVPZwYhMSBEsen2bkvWtgIO8zb3ZNn2TUblyTAxFxjw8Laa2hngLv/uZxBFQ2zKtb3vfSM/W8rXTmdeBfn+RDpC62Y=;7:/7kFZ5zB1bEoVOTQtr6237EYVs4EvW3B1P6QUjJlzuLhIvwH5H5vy6pTA39x6n4nQu0s3ynQo47CqclayMI0hoOBGy6jB15PN8g/2dI8F4VqGM5oDyIXMb+DyzCsh0sdIABR73CldKTgaPOn/l6XlE0QZngLHPFpaZqng7cxtMk6jPq6BNVwhAvgvGIoDtgSYkRj8VIvghnxIvv8C7WsOQ37ZGN8CLbWD1buLOCmt8yfaksIjhg74btM0gkCG3ZP SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;HE1PR0801MB1338;20:oRsY9ddjsKb2plm2yqTYFnLKjTi5wx3cxkt/OXtFfA23/x4Hm2hyHcjHT2CggKK/58P6D9/GTqEox1pVzxwEnrvNKn9uUyMgQBSDcIXC96qw73N+0te9aycvU5x8QNiEdO4ar0fgiW7YPq7Ga5bb5D1VVgCOQ/4rN5Z5pkPRAqE= X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Feb 2018 07:57:33.9036 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d71ddee2-bf82-4d3e-ccff-08d56e00729b X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0801MB1338 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07.02.2018 08:02, Paul E. McKenney wrote: > On Tue, Feb 06, 2018 at 08:23:34PM -0800, Matthew Wilcox wrote: >> On Tue, Feb 06, 2018 at 06:17:03PM -0800, Paul E. McKenney wrote: >>> So it is OK to kvmalloc() something and pass it to either kfree() or >>> kvfree(), and it had better be OK to kvmalloc() something and pass it >>> to kvfree(). >>> >>> Is it OK to kmalloc() something and pass it to kvfree()? >> >> Yes, it absolutely is. >> >> void kvfree(const void *addr) >> { >> if (is_vmalloc_addr(addr)) >> vfree(addr); >> else >> kfree(addr); >> } >> >>> If so, is it really useful to have two different names here, that is, >>> both kfree_rcu() and kvfree_rcu()? >> >> I think it's handy to have all three of kvfree_rcu(), kfree_rcu() and >> vfree_rcu() available in the API for the symmetry of calling kmalloc() >> / kfree_rcu(). >> >> Personally, I would like us to rename kvfree() to just free(), and have >> malloc(x) be an alias to kvmalloc(x, GFP_KERNEL), but I haven't won that >> fight yet. > > But why not just have the existing kfree_rcu() API cover both kmalloc() > and kvmalloc()? Perhaps I am not in the right forums, but I am not hearing > anyone arguing that the RCU API has too few members. ;-) People, far from RCU internals, consider kfree_rcu() like an extension of kfree(). And it's not clear it's need to dive into kfree_rcu() comments, when someone is looking a primitive to free vmalloc'ed memory. Also, construction like obj = kvmalloc(); kfree_rcu(obj); makes me think it's legitimately to use plain kfree() as pair bracket to kvmalloc(). So the significant change of kfree_rcu() behavior will complicate stable backporters life, because they will need to keep in mind such differences between different kernel versions. It seems if we are going to use the single primitive for both kmalloc() and kvmalloc() memory, it has to have another name. But I don't see problems with having both kfree_rcu() and kvfree_rcu(). Kirill From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753419AbeBGIU1 (ORCPT ); Wed, 7 Feb 2018 03:20:27 -0500 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:55362 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750815AbeBGIUZ (ORCPT ); Wed, 7 Feb 2018 03:20:25 -0500 Date: Wed, 7 Feb 2018 00:20:29 -0800 From: "Paul E. McKenney" To: Josh Triplett Cc: Matthew Wilcox , Kirill Tkhai , rostedt@goodmis.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, brouer@redhat.com, rao.shoaib@oracle.com Subject: Re: [PATCH 0/2] rcu: Transform kfree_rcu() into kvfree_rcu() Reply-To: paulmck@linux.vnet.ibm.com References: <151791170164.5994.8253310844733420079.stgit@localhost.localdomain> <20180207021703.GC3617@linux.vnet.ibm.com> <20180207042334.GA16175@bombadil.infradead.org> <20180207050200.GH3617@linux.vnet.ibm.com> <20180207075409.GA5726@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180207075409.GA5726@localhost> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 x-cbid: 18020708-2213-0000-0000-00000268E743 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00008489; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000248; SDB=6.00986147; UDB=6.00500439; IPR=6.00765514; BA=6.00005816; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00019419; XFM=3.00000015; UTC=2018-02-07 08:20:23 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18020708-2214-0000-0000-000059076B38 Message-Id: <20180207082029.GJ3617@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-02-07_02:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=2 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1802070106 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 06, 2018 at 11:54:09PM -0800, Josh Triplett wrote: > On Tue, Feb 06, 2018 at 09:02:00PM -0800, Paul E. McKenney wrote: > > On Tue, Feb 06, 2018 at 08:23:34PM -0800, Matthew Wilcox wrote: > > > On Tue, Feb 06, 2018 at 06:17:03PM -0800, Paul E. McKenney wrote: > > > > So it is OK to kvmalloc() something and pass it to either kfree() or > > > > kvfree(), and it had better be OK to kvmalloc() something and pass it > > > > to kvfree(). > > > > > > > > Is it OK to kmalloc() something and pass it to kvfree()? > > > > > > Yes, it absolutely is. > > > > > > void kvfree(const void *addr) > > > { > > > if (is_vmalloc_addr(addr)) > > > vfree(addr); > > > else > > > kfree(addr); > > > } > > > > > > > If so, is it really useful to have two different names here, that is, > > > > both kfree_rcu() and kvfree_rcu()? > > > > > > I think it's handy to have all three of kvfree_rcu(), kfree_rcu() and > > > vfree_rcu() available in the API for the symmetry of calling kmalloc() > > > / kfree_rcu(). > > > > > > Personally, I would like us to rename kvfree() to just free(), and have > > > malloc(x) be an alias to kvmalloc(x, GFP_KERNEL), but I haven't won that > > > fight yet. > > > > But why not just have the existing kfree_rcu() API cover both kmalloc() > > and kvmalloc()? Perhaps I am not in the right forums, but I am not hearing > > anyone arguing that the RCU API has too few members. ;-) > > I don't have any problem with having just `kvfree_rcu`, but having just > `kfree_rcu` seems confusingly asymmetric. I don't understand why kmalloc()/kvfree_rcu() would seem any less asymmetric than kvmalloc()/kfree_rcu(). > (Also, count me in favor of having just one "free" function, too.) We agree on that much, anyway. ;-) Thanx, Paul From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753519AbeBGIbB (ORCPT ); Wed, 7 Feb 2018 03:31:01 -0500 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:50776 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753491AbeBGIbA (ORCPT ); Wed, 7 Feb 2018 03:31:00 -0500 Date: Wed, 7 Feb 2018 00:31:04 -0800 From: "Paul E. McKenney" To: Kirill Tkhai Cc: Matthew Wilcox , josh@joshtriplett.org, rostedt@goodmis.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, brouer@redhat.com, rao.shoaib@oracle.com Subject: Re: [PATCH 0/2] rcu: Transform kfree_rcu() into kvfree_rcu() Reply-To: paulmck@linux.vnet.ibm.com References: <151791170164.5994.8253310844733420079.stgit@localhost.localdomain> <20180207021703.GC3617@linux.vnet.ibm.com> <20180207042334.GA16175@bombadil.infradead.org> <20180207050200.GH3617@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 x-cbid: 18020708-2213-0000-0000-00000268E81F X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00008489; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000248; SDB=6.00986151; UDB=6.00500441; IPR=6.00765517; BA=6.00005816; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00019419; XFM=3.00000015; UTC=2018-02-07 08:30:57 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18020708-2214-0000-0000-0000590770AE Message-Id: <20180207083104.GK3617@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-02-07_02:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=2 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1802070107 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 07, 2018 at 10:57:28AM +0300, Kirill Tkhai wrote: > On 07.02.2018 08:02, Paul E. McKenney wrote: > > On Tue, Feb 06, 2018 at 08:23:34PM -0800, Matthew Wilcox wrote: > >> On Tue, Feb 06, 2018 at 06:17:03PM -0800, Paul E. McKenney wrote: > >>> So it is OK to kvmalloc() something and pass it to either kfree() or > >>> kvfree(), and it had better be OK to kvmalloc() something and pass it > >>> to kvfree(). > >>> > >>> Is it OK to kmalloc() something and pass it to kvfree()? > >> > >> Yes, it absolutely is. > >> > >> void kvfree(const void *addr) > >> { > >> if (is_vmalloc_addr(addr)) > >> vfree(addr); > >> else > >> kfree(addr); > >> } > >> > >>> If so, is it really useful to have two different names here, that is, > >>> both kfree_rcu() and kvfree_rcu()? > >> > >> I think it's handy to have all three of kvfree_rcu(), kfree_rcu() and > >> vfree_rcu() available in the API for the symmetry of calling kmalloc() > >> / kfree_rcu(). > >> > >> Personally, I would like us to rename kvfree() to just free(), and have > >> malloc(x) be an alias to kvmalloc(x, GFP_KERNEL), but I haven't won that > >> fight yet. > > > > But why not just have the existing kfree_rcu() API cover both kmalloc() > > and kvmalloc()? Perhaps I am not in the right forums, but I am not hearing > > anyone arguing that the RCU API has too few members. ;-) > > People, far from RCU internals, consider kfree_rcu() like an extension > of kfree(). And it's not clear it's need to dive into kfree_rcu() comments, > when someone is looking a primitive to free vmalloc'ed memory. Seems like a relatively simple lesson to teach. > Also, construction like > > obj = kvmalloc(); > kfree_rcu(obj); > > makes me think it's legitimately to use plain kfree() as pair bracket to kvmalloc(). So it all works as is, then. > So the significant change of kfree_rcu() behavior will complicate stable backporters > life, because they will need to keep in mind such differences between different > kernel versions. If I understood your construction above, that significant change in kfree_rcu() behavior has already happened. > It seems if we are going to use the single primitive for both kmalloc() > and kvmalloc() memory, it has to have another name. But I don't see problems > with having both kfree_rcu() and kvfree_rcu(). 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. Thanx, Paul From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754212AbeBGN5F (ORCPT ); Wed, 7 Feb 2018 08:57:05 -0500 Received: from mail.kernel.org ([198.145.29.99]:48632 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753763AbeBGN5E (ORCPT ); Wed, 7 Feb 2018 08:57:04 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4CC882179F Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=goodmis.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=rostedt@goodmis.org Date: Wed, 7 Feb 2018 08:57:00 -0500 From: Steven Rostedt To: "Paul E. McKenney" Cc: Kirill Tkhai , Matthew Wilcox , 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, brouer@redhat.com, rao.shoaib@oracle.com Subject: Re: [PATCH 0/2] rcu: Transform kfree_rcu() into kvfree_rcu() Message-ID: <20180207085700.393f90d0@gandalf.local.home> In-Reply-To: <20180207083104.GK3617@linux.vnet.ibm.com> References: <151791170164.5994.8253310844733420079.stgit@localhost.localdomain> <20180207021703.GC3617@linux.vnet.ibm.com> <20180207042334.GA16175@bombadil.infradead.org> <20180207050200.GH3617@linux.vnet.ibm.com> <20180207083104.GK3617@linux.vnet.ibm.com> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 7 Feb 2018 00:31:04 -0800 "Paul E. McKenney" 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. -- Steve From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754368AbeBGOzv (ORCPT ); Wed, 7 Feb 2018 09:55:51 -0500 Received: from resqmta-ch2-10v.sys.comcast.net ([69.252.207.42]:47118 "EHLO resqmta-ch2-10v.sys.comcast.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754065AbeBGOzt (ORCPT ); Wed, 7 Feb 2018 09:55:49 -0500 Date: Wed, 7 Feb 2018 08:55:47 -0600 (CST) From: Christopher Lameter X-X-Sender: cl@nuc-kabylake To: "Paul E. McKenney" cc: Kirill Tkhai , josh@joshtriplett.org, rostedt@goodmis.org, mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com, mingo@redhat.com, penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, brouer@redhat.com, rao.shoaib@oracle.com Subject: Re: [PATCH 0/2] rcu: Transform kfree_rcu() into kvfree_rcu() In-Reply-To: <20180207021703.GC3617@linux.vnet.ibm.com> Message-ID: References: <151791170164.5994.8253310844733420079.stgit@localhost.localdomain> <20180207021703.GC3617@linux.vnet.ibm.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-CMAE-Envelope: MS4wfE0On2jR36NT55WiWuoVNGEc9NWPqC7qPMdDNPovqpNZO2GHagaUHizVn/pcoWX/tKn49Xaa9fT2tapaIBGcv5OiCwjTDHbWBITmrjPXZPA9aov7ka5Y EhLRG1AHMwwpq1g3786Ft0raVKVlM/WJP9VkO6CMRMoLgkWRRX9txx/9TK8b1XJxSe+kes212Ye+kx4DuekOn+42Lh8QhgRl7lUS0HvLNGW9g202x8pglYxB u5JtbKge3s35GmtTOcMtacsGL5e25JGKFpQtaCvrZZPeR6IIuQiS9HBrMEnXSOwS9l/UkuGX6WlsdDuV2/aLAu2trpgfQzkMGygdOSMcK1rZIdeiVs/dWbGY FZ7lfEAOvTHi7/VC8WDhmMSwUh0VfljKpVZ4u+hCCPs2eImozM3yeONcb+MJYgJSnk3Z6bte4Nm0LOaD85TJOifmeHbSAj+OLcID7Vc2VRtcJ7rSUVsKKQzb 5s95E568JzET7oprvHJthMkuPep8FW9gvD1u/AL7Gr38rtAetC1v0ZL6o9bE+8uTuCPgo+RutLkNAKTUhtcoemSK2eulEktJfl4yrZOgGmQ2sW2mtBRfZhFN yY12TXKoTLb3E2dLrrozP85JixYnJGU/iKQ4xr7Sr8jUiA== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 6 Feb 2018, Paul E. McKenney wrote: > So it is OK to kvmalloc() something and pass it to either kfree() or > kvfree(), and it had better be OK to kvmalloc() something and pass it > to kvfree(). kvfree() is fine but not kfree(). From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754665AbeBGQTB (ORCPT ); Wed, 7 Feb 2018 11:19:01 -0500 Received: from bombadil.infradead.org ([65.50.211.133]:51685 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754392AbeBGQS7 (ORCPT ); Wed, 7 Feb 2018 11:18:59 -0500 Date: Wed, 7 Feb 2018 08:18:46 -0800 From: Matthew Wilcox To: Steven Rostedt Cc: "Paul E. McKenney" , Kirill Tkhai , 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, brouer@redhat.com, rao.shoaib@oracle.com Subject: Re: [PATCH 0/2] rcu: Transform kfree_rcu() into kvfree_rcu() Message-ID: <20180207161846.GA902@bombadil.infradead.org> References: <151791170164.5994.8253310844733420079.stgit@localhost.localdomain> <20180207021703.GC3617@linux.vnet.ibm.com> <20180207042334.GA16175@bombadil.infradead.org> <20180207050200.GH3617@linux.vnet.ibm.com> <20180207083104.GK3617@linux.vnet.ibm.com> <20180207085700.393f90d0@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180207085700.393f90d0@gandalf.local.home> User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 07, 2018 at 08:57:00AM -0500, Steven Rostedt wrote: > On Wed, 7 Feb 2018 00:31:04 -0800 > "Paul E. McKenney" 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 You missed kvmalloc() ... > 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. I'd still like it to be called free_rcu() ... so let's turn it around. What memory can you allocate and then *not* free by calling kvfree()? kvfree() can free memory allocated by kmalloc(), vmalloc(), any slab allocation (is that guaranteed, or just something that happens to work?) I think it can't free per-cpu allocations, bootmem, DMA allocations, or alloc_page/get_free_page. Do we need to be able to free any of those objects in order to rename kfree_rcu() to just free_rcu()? From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932130AbeBGQeV (ORCPT ); Wed, 7 Feb 2018 11:34:21 -0500 Received: from mail.kernel.org ([198.145.29.99]:37238 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754466AbeBGQeT (ORCPT ); Wed, 7 Feb 2018 11:34:19 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9300D21788 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=goodmis.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=rostedt@goodmis.org Date: Wed, 7 Feb 2018 11:34:16 -0500 From: Steven Rostedt To: Matthew Wilcox Cc: "Paul E. McKenney" , Kirill Tkhai , 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, brouer@redhat.com, rao.shoaib@oracle.com Subject: Re: [PATCH 0/2] rcu: Transform kfree_rcu() into kvfree_rcu() Message-ID: <20180207113416.33b6247b@gandalf.local.home> In-Reply-To: <20180207161846.GA902@bombadil.infradead.org> References: <151791170164.5994.8253310844733420079.stgit@localhost.localdomain> <20180207021703.GC3617@linux.vnet.ibm.com> <20180207042334.GA16175@bombadil.infradead.org> <20180207050200.GH3617@linux.vnet.ibm.com> <20180207083104.GK3617@linux.vnet.ibm.com> <20180207085700.393f90d0@gandalf.local.home> <20180207161846.GA902@bombadil.infradead.org> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 7 Feb 2018 08:18:46 -0800 Matthew Wilcox wrote: > Do we need to be able to free any of those objects in order to rename > kfree_rcu() to just free_rcu()? I'm just nervous about tightly coupling free_rcu() with all the *free() from the memory management system. I've been burnt in the past by doing such things. What's the down side of having a way of matching *free_rcu() with all the *free()s? I think it's easier to understand, and rcu doesn't need to worry about changes of *free() code. To me: kfree_rcu(x); is just a quick way of doing 'kfree(x)' after a synchronize_rcu() call. But a "free_rcu(x)", is something I have to think about, because I don't know from the name exactly what it is doing. I know this may sound a bit bike shedding, but the less I need to think about how other sub systems work, the easier it is to concentrate on my own sub system. -- Steve From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754700AbeBGQpZ (ORCPT ); Wed, 7 Feb 2018 11:45:25 -0500 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:57416 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754377AbeBGQpX (ORCPT ); Wed, 7 Feb 2018 11:45:23 -0500 Date: Wed, 7 Feb 2018 17:45:13 +0100 From: Jesper Dangaard Brouer To: Steven Rostedt Cc: "Paul E. McKenney" , Kirill Tkhai , Matthew Wilcox , 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() Message-ID: <20180207174513.5cc9b503@redhat.com> In-Reply-To: <20180207085700.393f90d0@gandalf.local.home> References: <151791170164.5994.8253310844733420079.stgit@localhost.localdomain> <20180207021703.GC3617@linux.vnet.ibm.com> <20180207042334.GA16175@bombadil.infradead.org> <20180207050200.GH3617@linux.vnet.ibm.com> <20180207083104.GK3617@linux.vnet.ibm.com> <20180207085700.393f90d0@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 7 Feb 2018 08:57:00 -0500 Steven Rostedt wrote: > On Wed, 7 Feb 2018 00:31:04 -0800 > "Paul E. McKenney" 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 } From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754708AbeBGQrH (ORCPT ); Wed, 7 Feb 2018 11:47:07 -0500 Received: from resqmta-ch2-08v.sys.comcast.net ([69.252.207.40]:60038 "EHLO resqmta-ch2-08v.sys.comcast.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754490AbeBGQrG (ORCPT ); Wed, 7 Feb 2018 11:47:06 -0500 Date: Wed, 7 Feb 2018 10:47:02 -0600 (CST) From: Christopher Lameter X-X-Sender: cl@nuc-kabylake To: Matthew Wilcox cc: "Paul E. McKenney" , Kirill Tkhai , josh@joshtriplett.org, rostedt@goodmis.org, mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com, mingo@redhat.com, penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, brouer@redhat.com, rao.shoaib@oracle.com Subject: Re: [PATCH 0/2] rcu: Transform kfree_rcu() into kvfree_rcu() In-Reply-To: <20180207042334.GA16175@bombadil.infradead.org> Message-ID: References: <151791170164.5994.8253310844733420079.stgit@localhost.localdomain> <20180207021703.GC3617@linux.vnet.ibm.com> <20180207042334.GA16175@bombadil.infradead.org> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-CMAE-Envelope: MS4wfHGw4Hvcp66gHBR1iIk5FV5wgIHfe9u53KpyriSGpy1EIkkf4TKuO2e4f+5ONwLIJhnw6Jf/ryLIp359IwuLpuwr/McjMuXl9LyTFEhI4+lMCF7ZmMqT IJOsCv18BZGE1QnNblzvw0KfT/8JDnsp6OojkOJvm8eKsx6xXYjHdYnf0tRrDrqyWq1NoFzumYC2Aab4z1pmXpd6DUYQSQWOBw5bZl5Iy1P7SaDgkuVFw2Qu 1Axr7B+iunfD0H0jbVS65JvT1Xo5IaXNGShaWExl5+nvZuYB0ftPBWlRwHf3mxDviTpXmMuGjlosFhe9H0ljB58ksvf4di+WSmKb5L1O2Aw2DWYoCiXrDgwf jZ2PjZWRNKFVDMIEvYKYcR4eBrWgCp+O5q8Teki+DOzaEwJKN8Hcu6TlAKw4sHd7DzJQb4vVIBBv5XDhl2unFvP0ZW2FqNXE+WsUhfhRFCLb4ka4rpmC/bUr W/crs4YRIgvSCp0L/9arkJv3rRMpPfwYuXA/k+TFqarNtA5VNfA8A0eMbbLlfcW6iuB9n1kE4moZIfjcvsNZ9ZICHQ3hHafDOCrlis5UccojcGn1WgpiPgdB VL5eYvBPe6+akpl2cKqP3UEHUdMHwtVEh0A0NKtDkIYSIJJ3EW5eUcV+1riVh2TimX87/pynRXtiVRnpCACF8dCf Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 6 Feb 2018, Matthew Wilcox wrote: > Personally, I would like us to rename kvfree() to just free(), and have > malloc(x) be an alias to kvmalloc(x, GFP_KERNEL), but I haven't won that > fight yet. Maybe lets implement malloc(), free() and realloc() in the kernel to be consistent with user space use as possible? Only use the others allocation variants for special cases. So malloc would check allocation sizes and if < 2* PAGE_SIZE use kmalloc() otherwise vmalloc(). free() would free anything you give it. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754662AbeBGRJx (ORCPT ); Wed, 7 Feb 2018 12:09:53 -0500 Received: from mail.kernel.org ([198.145.29.99]:41008 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753390AbeBGRJw (ORCPT ); Wed, 7 Feb 2018 12:09:52 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BC63921788 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=goodmis.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=rostedt@goodmis.org Date: Wed, 7 Feb 2018 12:09:49 -0500 From: Steven Rostedt To: Christopher Lameter Cc: Matthew Wilcox , "Paul E. McKenney" , Kirill Tkhai , josh@joshtriplett.org, mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com, mingo@redhat.com, penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, brouer@redhat.com, rao.shoaib@oracle.com Subject: Re: [PATCH 0/2] rcu: Transform kfree_rcu() into kvfree_rcu() Message-ID: <20180207120949.62fa815f@gandalf.local.home> In-Reply-To: References: <151791170164.5994.8253310844733420079.stgit@localhost.localdomain> <20180207021703.GC3617@linux.vnet.ibm.com> <20180207042334.GA16175@bombadil.infradead.org> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 7 Feb 2018 10:47:02 -0600 (CST) Christopher Lameter wrote: > On Tue, 6 Feb 2018, Matthew Wilcox wrote: > > > Personally, I would like us to rename kvfree() to just free(), and have > > malloc(x) be an alias to kvmalloc(x, GFP_KERNEL), but I haven't won that > > fight yet. > > Maybe lets implement malloc(), free() and realloc() in the kernel to be > consistent with user space use as possible? Only use the others > allocation variants for special cases. They would need to drop the GFP part and default to GFP_KERNEL. > > So malloc would check allocation sizes and if < 2* PAGE_SIZE use kmalloc() > otherwise vmalloc(). Please no, I hate subtle internal decisions like this. It makes debugging much more difficult, when allocating dynamic sized variables. When something works at one size but not the other. -- Steve > > free() would free anything you give it. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754773AbeBGRT6 (ORCPT ); Wed, 7 Feb 2018 12:19:58 -0500 Received: from bombadil.infradead.org ([65.50.211.133]:58857 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754528AbeBGRT5 (ORCPT ); Wed, 7 Feb 2018 12:19:57 -0500 Date: Wed, 7 Feb 2018 09:19:36 -0800 From: Matthew Wilcox To: Steven Rostedt Cc: Christopher Lameter , "Paul E. McKenney" , Kirill Tkhai , josh@joshtriplett.org, mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com, mingo@redhat.com, penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, brouer@redhat.com, rao.shoaib@oracle.com Subject: Re: [PATCH 0/2] rcu: Transform kfree_rcu() into kvfree_rcu() Message-ID: <20180207171936.GA12446@bombadil.infradead.org> References: <151791170164.5994.8253310844733420079.stgit@localhost.localdomain> <20180207021703.GC3617@linux.vnet.ibm.com> <20180207042334.GA16175@bombadil.infradead.org> <20180207120949.62fa815f@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180207120949.62fa815f@gandalf.local.home> User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 07, 2018 at 12:09:49PM -0500, Steven Rostedt wrote: > > Maybe lets implement malloc(), free() and realloc() in the kernel to be > > consistent with user space use as possible? Only use the others > > allocation variants for special cases. > > They would need to drop the GFP part and default to GFP_KERNEL. Yes, exactly. > > So malloc would check allocation sizes and if < 2* PAGE_SIZE use kmalloc() > > otherwise vmalloc(). > > Please no, I hate subtle internal decisions like this. It makes > debugging much more difficult, when allocating dynamic sized variables. > When something works at one size but not the other. You know we already have kvmalloc()? From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754972AbeBGR3Q (ORCPT ); Wed, 7 Feb 2018 12:29:16 -0500 Received: from mail.kernel.org ([198.145.29.99]:43224 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754693AbeBGR3O (ORCPT ); Wed, 7 Feb 2018 12:29:14 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B59422172C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=goodmis.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=rostedt@goodmis.org Date: Wed, 7 Feb 2018 12:29:10 -0500 From: Steven Rostedt To: Matthew Wilcox Cc: Christopher Lameter , "Paul E. McKenney" , Kirill Tkhai , josh@joshtriplett.org, mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com, mingo@redhat.com, penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, brouer@redhat.com, rao.shoaib@oracle.com Subject: Re: [PATCH 0/2] rcu: Transform kfree_rcu() into kvfree_rcu() Message-ID: <20180207122910.1a91a48e@gandalf.local.home> In-Reply-To: <20180207171936.GA12446@bombadil.infradead.org> References: <151791170164.5994.8253310844733420079.stgit@localhost.localdomain> <20180207021703.GC3617@linux.vnet.ibm.com> <20180207042334.GA16175@bombadil.infradead.org> <20180207120949.62fa815f@gandalf.local.home> <20180207171936.GA12446@bombadil.infradead.org> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 7 Feb 2018 09:19:36 -0800 Matthew Wilcox wrote: > > Please no, I hate subtle internal decisions like this. It makes > > debugging much more difficult, when allocating dynamic sized variables. > > When something works at one size but not the other. > > You know we already have kvmalloc()? Yes, and the name suggests exactly what it does. It has both "k" and "v" which tells me that if I use it it could be one or the other. But a generic "malloc" or "free" that does things differently depending on the size is a different story. -- Steve From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754278AbeBGRy1 (ORCPT ); Wed, 7 Feb 2018 12:54:27 -0500 Received: from resqmta-ch2-11v.sys.comcast.net ([69.252.207.43]:51412 "EHLO resqmta-ch2-11v.sys.comcast.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753896AbeBGRyZ (ORCPT ); Wed, 7 Feb 2018 12:54:25 -0500 Date: Wed, 7 Feb 2018 11:54:22 -0600 (CST) From: Christopher Lameter X-X-Sender: cl@nuc-kabylake To: Steven Rostedt cc: Matthew Wilcox , "Paul E. McKenney" , Kirill Tkhai , josh@joshtriplett.org, mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com, mingo@redhat.com, penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, brouer@redhat.com, rao.shoaib@oracle.com Subject: Re: [PATCH 0/2] rcu: Transform kfree_rcu() into kvfree_rcu() In-Reply-To: <20180207122910.1a91a48e@gandalf.local.home> Message-ID: References: <151791170164.5994.8253310844733420079.stgit@localhost.localdomain> <20180207021703.GC3617@linux.vnet.ibm.com> <20180207042334.GA16175@bombadil.infradead.org> <20180207120949.62fa815f@gandalf.local.home> <20180207171936.GA12446@bombadil.infradead.org> <20180207122910.1a91a48e@gandalf.local.home> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-CMAE-Envelope: MS4wfOnw7sutZvncgfyDJO89s+RkTHRH3/dniDNsnIDaRi91Vl1cOcWuONdCZpOAt4YuyHOHQOGgs8JdCC3UciNnRFEtgPTYLxP51vh121ZiGJzRd7zHoHkY i4Hqs4ISZMFsjXFL467BDDnUG8sz8tyxbFIgIninIoa/EQZTM8JsdhfkqbEIEOh7t6Yhn7ex7kLkvAQENdNPc/L9SHopQ8gEDzlEKAvJjmTkqhNR1hZoZoXN XiB1sewFnsLTh8fDYWqPUp9EYVJSmhT8eloAp0OPKVfHJ+PEXrhmC/bt3dzKI8dX8ffzacrSflt599Zre260D0UMYgCVxNkU4mc0FSquZJRcofNuJ9+ZThUc Vruyxl0X+xUPKaZqNluIpDIXdjgKctZ6JBhYeOY8U9RryfMWMMc/jiuAWYClyvHDil0Ao0uo4e2AjeYoXZGadcxqy1M3X1rmerr1V5uw6xbAgjpDwHPpCEJI HKSyLr3OrOxcmokq6VSC38b97kAcn8vGVoUVjaDtmcKVYW1y1nx/5PGTsxG6GDAwkhbxdi09/4K6mOuEthk69nlN+uQt06Gu9uvxue6gKYFHCdgrnmENY1wZ efIpfoqdbCE+kXOjLBir8HAwx2SUJ0YLnURu9gLrpJ9J4tNmJlhRohtROF4nIkKKdxkWRb/VRZ2HYbx7EmaePSrk Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 7 Feb 2018, Steven Rostedt wrote: > But a generic "malloc" or "free" that does things differently depending > on the size is a different story. They would not be used for cases with special requirements but for the throwaway allows where noone cares about these details. Its just a convenience for the developers that do not need to be bothered with too much detail because they are not dealing with codepaths that have special requirements. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754204AbeBGSLJ (ORCPT ); Wed, 7 Feb 2018 13:11:09 -0500 Received: from bombadil.infradead.org ([65.50.211.133]:49151 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754002AbeBGSLH (ORCPT ); Wed, 7 Feb 2018 13:11:07 -0500 Date: Wed, 7 Feb 2018 10:10:55 -0800 From: Matthew Wilcox To: Jesper Dangaard Brouer Cc: Steven Rostedt , "Paul E. McKenney" , Kirill Tkhai , 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 Subject: Re: [PATCH 0/2] rcu: Transform kfree_rcu() into kvfree_rcu() Message-ID: <20180207181055.GB12446@bombadil.infradead.org> References: <151791170164.5994.8253310844733420079.stgit@localhost.localdomain> <20180207021703.GC3617@linux.vnet.ibm.com> <20180207042334.GA16175@bombadil.infradead.org> <20180207050200.GH3617@linux.vnet.ibm.com> <20180207083104.GK3617@linux.vnet.ibm.com> <20180207085700.393f90d0@gandalf.local.home> <20180207174513.5cc9b503@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180207174513.5cc9b503@redhat.com> User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 07, 2018 at 05:45:13PM +0100, Jesper Dangaard Brouer wrote: > On Wed, 7 Feb 2018 08:57:00 -0500 > Steven Rostedt wrote: > > 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" ;-)) While free_rcu() is not withut its performance requirements, I think it's currently dominated by cache misses and not by branches. By the time RCU gets to run callbacks, memory is certainly L1/L2 cache-cold and probably L3 cache-cold. Also calling the callback functions is utterly impossible for the branch predictor. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754087AbeBGS0X (ORCPT ); Wed, 7 Feb 2018 13:26:23 -0500 Received: from mail.kernel.org ([198.145.29.99]:51702 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753390AbeBGS0W (ORCPT ); Wed, 7 Feb 2018 13:26:22 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AA65720835 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=goodmis.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=rostedt@goodmis.org Date: Wed, 7 Feb 2018 13:26:19 -0500 From: Steven Rostedt To: Matthew Wilcox Cc: Jesper Dangaard Brouer , "Paul E. McKenney" , Kirill Tkhai , 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 Subject: Re: [PATCH 0/2] rcu: Transform kfree_rcu() into kvfree_rcu() Message-ID: <20180207132619.6595e4a9@gandalf.local.home> In-Reply-To: <20180207181055.GB12446@bombadil.infradead.org> References: <151791170164.5994.8253310844733420079.stgit@localhost.localdomain> <20180207021703.GC3617@linux.vnet.ibm.com> <20180207042334.GA16175@bombadil.infradead.org> <20180207050200.GH3617@linux.vnet.ibm.com> <20180207083104.GK3617@linux.vnet.ibm.com> <20180207085700.393f90d0@gandalf.local.home> <20180207174513.5cc9b503@redhat.com> <20180207181055.GB12446@bombadil.infradead.org> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 7 Feb 2018 10:10:55 -0800 Matthew Wilcox wrote: > > For the record, I fully agree with Steve here. Thanks, but... > > > > 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" ;-)) > > While free_rcu() is not withut its performance requirements, I think it's > currently dominated by cache misses and not by branches. By the time RCU > gets to run callbacks, memory is certainly L1/L2 cache-cold and probably > L3 cache-cold. Also calling the callback functions is utterly impossible > for the branch predictor. I agree with Matthew. This is far from any fast path. A few extra branches isn't going to hurt anything here as it's mostly just garbage collection. With or without the Spectre fixes. -- Steve From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751671AbeBHEJG (ORCPT ); Wed, 7 Feb 2018 23:09:06 -0500 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:59622 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750806AbeBHEJF (ORCPT ); Wed, 7 Feb 2018 23:09:05 -0500 Date: Wed, 7 Feb 2018 20:09:10 -0800 From: "Paul E. McKenney" To: Steven Rostedt Cc: Kirill Tkhai , Matthew Wilcox , 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, brouer@redhat.com, rao.shoaib@oracle.com Subject: Re: [PATCH 0/2] rcu: Transform kfree_rcu() into kvfree_rcu() Reply-To: paulmck@linux.vnet.ibm.com References: <151791170164.5994.8253310844733420079.stgit@localhost.localdomain> <20180207021703.GC3617@linux.vnet.ibm.com> <20180207042334.GA16175@bombadil.infradead.org> <20180207050200.GH3617@linux.vnet.ibm.com> <20180207083104.GK3617@linux.vnet.ibm.com> <20180207085700.393f90d0@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180207085700.393f90d0@gandalf.local.home> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 x-cbid: 18020804-0056-0000-0000-000004178450 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00008494; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000249; SDB=6.00986543; UDB=6.00500676; IPR=6.00765907; BA=6.00005819; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00019434; XFM=3.00000015; UTC=2018-02-08 04:09:02 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18020804-0057-0000-0000-0000084EF46C Message-Id: <20180208040910.GP3617@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-02-08_01:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1802080035 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 07, 2018 at 08:57:00AM -0500, Steven Rostedt wrote: > On Wed, 7 Feb 2018 00:31:04 -0800 > "Paul E. McKenney" 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. I couldn't agree more! To that end, what are your thoughts on this patch? https://lkml.kernel.org/r/1513895570-28640-1-git-send-email-rao.shoaib@oracle.com Advantages include the ability to optimize based on sl[aou]b state, getting rid of the 4K offset hack in __is_kfree_rcu_offset(), better cache localite, and, as you say, putting the naming responsibility in the memory-management domain. > 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. And that is one reason I am viewing the name-change patch with great suspicion, especially given that there seems to be some controversy among the memory-management folks as to exactly what the names should be. Thanx, Paul From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752053AbeBHEJ1 (ORCPT ); Wed, 7 Feb 2018 23:09:27 -0500 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:38492 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751153AbeBHEJ0 (ORCPT ); Wed, 7 Feb 2018 23:09:26 -0500 Date: Wed, 7 Feb 2018 20:09:29 -0800 From: "Paul E. McKenney" To: Christopher Lameter Cc: Kirill Tkhai , josh@joshtriplett.org, rostedt@goodmis.org, mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com, mingo@redhat.com, penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, brouer@redhat.com, rao.shoaib@oracle.com Subject: Re: [PATCH 0/2] rcu: Transform kfree_rcu() into kvfree_rcu() Reply-To: paulmck@linux.vnet.ibm.com References: <151791170164.5994.8253310844733420079.stgit@localhost.localdomain> <20180207021703.GC3617@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 x-cbid: 18020804-0008-0000-0000-000002CE9021 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00008494; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000249; SDB=6.00986543; UDB=6.00500676; IPR=6.00765907; BA=6.00005819; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00019434; XFM=3.00000015; UTC=2018-02-08 04:09:22 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18020804-0009-0000-0000-0000382FFFD5 Message-Id: <20180208040929.GQ3617@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-02-08_01:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1802080036 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 07, 2018 at 08:55:47AM -0600, Christopher Lameter wrote: > On Tue, 6 Feb 2018, Paul E. McKenney wrote: > > > So it is OK to kvmalloc() something and pass it to either kfree() or > > kvfree(), and it had better be OK to kvmalloc() something and pass it > > to kvfree(). > > kvfree() is fine but not kfree(). Ah, even more fun, then! ;-) Thanx, Paul From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751986AbeBHEKh (ORCPT ); Wed, 7 Feb 2018 23:10:37 -0500 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:44012 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751269AbeBHEKf (ORCPT ); Wed, 7 Feb 2018 23:10:35 -0500 Date: Wed, 7 Feb 2018 20:10:39 -0800 From: "Paul E. McKenney" To: Steven Rostedt Cc: Matthew Wilcox , Jesper Dangaard Brouer , Kirill Tkhai , 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 Subject: Re: [PATCH 0/2] rcu: Transform kfree_rcu() into kvfree_rcu() Reply-To: paulmck@linux.vnet.ibm.com References: <151791170164.5994.8253310844733420079.stgit@localhost.localdomain> <20180207021703.GC3617@linux.vnet.ibm.com> <20180207042334.GA16175@bombadil.infradead.org> <20180207050200.GH3617@linux.vnet.ibm.com> <20180207083104.GK3617@linux.vnet.ibm.com> <20180207085700.393f90d0@gandalf.local.home> <20180207174513.5cc9b503@redhat.com> <20180207181055.GB12446@bombadil.infradead.org> <20180207132619.6595e4a9@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180207132619.6595e4a9@gandalf.local.home> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 x-cbid: 18020804-0056-0000-0000-000004178461 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00008494; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000249; SDB=6.00986544; UDB=6.00500676; IPR=6.00765908; BA=6.00005819; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00019434; XFM=3.00000015; UTC=2018-02-08 04:10:31 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18020804-0057-0000-0000-0000084EF47D Message-Id: <20180208041039.GR3617@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-02-08_01:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=2 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1802080036 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 07, 2018 at 01:26:19PM -0500, Steven Rostedt wrote: > On Wed, 7 Feb 2018 10:10:55 -0800 > Matthew Wilcox wrote: > > > > For the record, I fully agree with Steve here. > > Thanks, but... > > > > > > > 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" ;-)) > > > > While free_rcu() is not withut its performance requirements, I think it's > > currently dominated by cache misses and not by branches. By the time RCU > > gets to run callbacks, memory is certainly L1/L2 cache-cold and probably > > L3 cache-cold. Also calling the callback functions is utterly impossible > > for the branch predictor. > > I agree with Matthew. > > This is far from any fast path. A few extra branches isn't going to > hurt anything here as it's mostly just garbage collection. With or > without the Spectre fixes. What Steve said! Thanx, Paul From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751945AbeBVXzQ (ORCPT ); Thu, 22 Feb 2018 18:55:16 -0500 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:48840 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751283AbeBVXzP (ORCPT ); Thu, 22 Feb 2018 18:55:15 -0500 Date: Thu, 22 Feb 2018 15:55:32 -0800 From: "Paul E. McKenney" To: Matthew Wilcox Cc: Jesper Dangaard Brouer , Steven Rostedt , Kirill Tkhai , 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 Subject: Re: [PATCH 0/2] rcu: Transform kfree_rcu() into kvfree_rcu() Reply-To: paulmck@linux.vnet.ibm.com References: <151791170164.5994.8253310844733420079.stgit@localhost.localdomain> <20180207021703.GC3617@linux.vnet.ibm.com> <20180207042334.GA16175@bombadil.infradead.org> <20180207050200.GH3617@linux.vnet.ibm.com> <20180207083104.GK3617@linux.vnet.ibm.com> <20180207085700.393f90d0@gandalf.local.home> <20180207174513.5cc9b503@redhat.com> <20180207181055.GB12446@bombadil.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180207181055.GB12446@bombadil.infradead.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 x-cbid: 18022223-0056-0000-0000-00000422A8CB X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00008579; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000254; SDB=6.00993655; UDB=6.00504921; IPR=6.00772995; MB=3.00019696; MTD=3.00000008; XFM=3.00000015; UTC=2018-02-22 23:55:12 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18022223-0057-0000-0000-00000864AF76 Message-Id: <20180222235532.GA11181@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-02-22_09:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=2 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1802220296 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 07, 2018 at 10:10:55AM -0800, Matthew Wilcox wrote: > On Wed, Feb 07, 2018 at 05:45:13PM +0100, Jesper Dangaard Brouer wrote: > > On Wed, 7 Feb 2018 08:57:00 -0500 > > Steven Rostedt wrote: > > > 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" ;-)) > > While free_rcu() is not withut its performance requirements, I think it's > currently dominated by cache misses and not by branches. By the time RCU > gets to run callbacks, memory is certainly L1/L2 cache-cold and probably > L3 cache-cold. Also calling the callback functions is utterly impossible > for the branch predictor. This seems to have fallen by the wayside. To get things going again, I suggest starting out by simply replacing the kfree() in __rcu_reclaim() with kvfree(). If desired, a kvfree_rcu() can also be defined as a synonym for kfree_rcu(). This gets us a very simple and small patch which provides the ability to dispose of kvmalloc() memory after a grace period. Thanx, Paul