From: Kirill Tkhai <ktkhai@virtuozzo.com>
To: Steven Rostedt <rostedt@goodmis.org>
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()
Date: Tue, 6 Feb 2018 18:06:33 +0300 [thread overview]
Message-ID: <52fe3917-cf72-d512-8422-d53bacf40113@virtuozzo.com> (raw)
In-Reply-To: <20180206093451.0de5ceeb@gandalf.local.home>
On 06.02.2018 17:34, Steven Rostedt wrote:
> On Tue, 06 Feb 2018 13:19:45 +0300
> Kirill Tkhai <ktkhai@virtuozzo.com> 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);
>> }
next prev parent reply other threads:[~2018-02-06 15:06 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-06 10:19 [PATCH 0/2] " Kirill Tkhai
2018-02-06 10:19 ` [PATCH 1/2] " Kirill Tkhai
2018-02-06 14:34 ` Steven Rostedt
2018-02-06 15:06 ` Kirill Tkhai [this message]
2018-02-06 15:49 ` Steven Rostedt
2018-02-06 10:19 ` [PATCH 2/2] mm: Use kvfree_rcu() in update_memcg_params() Kirill Tkhai
2018-02-07 2:17 ` [PATCH 0/2] rcu: Transform kfree_rcu() into kvfree_rcu() Paul E. McKenney
2018-02-07 4:23 ` Matthew Wilcox
2018-02-07 5:02 ` Paul E. McKenney
2018-02-07 7:54 ` Josh Triplett
2018-02-07 8:20 ` Paul E. McKenney
2018-02-07 7:57 ` Kirill Tkhai
2018-02-07 8:31 ` Paul E. McKenney
2018-02-07 13:57 ` Steven Rostedt
2018-02-07 16:18 ` Matthew Wilcox
2018-02-07 16:34 ` Steven Rostedt
2018-02-07 16:45 ` Jesper Dangaard Brouer
2018-02-07 18:10 ` Matthew Wilcox
2018-02-07 18:26 ` Steven Rostedt
2018-02-08 4:10 ` Paul E. McKenney
2018-02-22 23:55 ` Paul E. McKenney
2018-02-08 4:09 ` Paul E. McKenney
2018-02-07 16:47 ` Christopher Lameter
2018-02-07 17:09 ` Steven Rostedt
2018-02-07 17:19 ` Matthew Wilcox
2018-02-07 17:29 ` Steven Rostedt
2018-02-07 17:54 ` Christopher Lameter
2018-02-07 14:55 ` Christopher Lameter
2018-02-08 4:09 ` Paul E. McKenney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52fe3917-cf72-d512-8422-d53bacf40113@virtuozzo.com \
--to=ktkhai@virtuozzo.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=jiangshanlai@gmail.com \
--cc=josh@joshtriplett.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mingo@redhat.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=rostedt@goodmis.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®