From: Uladzislau Rezki <urezki@gmail.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Uladzislau Rezki <urezki@gmail.com>,
LKML <linux-kernel@vger.kernel.org>, RCU <rcu@vger.kernel.org>,
"Paul E . McKenney" <paulmck@kernel.org>,
Oleksiy Avramchenko <oleksiy.avramchenko@sony.com>,
Jens Axboe <axboe@kernel.dk>,
Philipp Reisner <philipp.reisner@linbit.com>,
Bryan Tan <bryantan@vmware.com>,
Eric Dumazet <edumazet@google.com>,
Bob Pearson <rpearsonhpe@gmail.com>,
Ariel Levkovich <lariel@nvidia.com>,
Theodore Ts'o <tytso@mit.edu>, Julian Anastasov <ja@ssi.bg>
Subject: Re: [PATCH 04/13] tracing: Rename kvfree_rcu() to kvfree_rcu_mightsleep()
Date: Thu, 16 Mar 2023 09:16:37 +0100 [thread overview]
Message-ID: <ZBLQZSm+SuazEODN@pc636> (raw)
In-Reply-To: <20230315183648.5164af0f@gandalf.local.home>
> On Thu, 9 Mar 2023 14:45:21 +0100
> Uladzislau Rezki <urezki@gmail.com> wrote:
>
> > > The kvfree_rcu()'s single argument name is deprecated therefore
> > > rename it to kvfree_rcu_mightsleep() variant. The goal is explicitly
> > > underline that it is for sleepable contexts.
> > >
> > > Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
> > > Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
> > >
> > Could you please add you reviwed-by or Acked-by tags so we can bring
> > our series with renaming for the next merge window?
>
> I don't know. Perhaps we should just apply this patch and not worry about
> sleeping and whatnot.
>
> -- Steve
>
> diff --git a/kernel/trace/trace_osnoise.c b/kernel/trace/trace_osnoise.c
> index 04f0fdae19a1..5de945a8f61d 100644
> --- a/kernel/trace/trace_osnoise.c
> +++ b/kernel/trace/trace_osnoise.c
> @@ -76,6 +76,7 @@ static unsigned long osnoise_options = OSN_DEFAULT_OPTIONS;
> struct osnoise_instance {
> struct list_head list;
> struct trace_array *tr;
> + struct rcu_head rcu;
> };
>
> static struct list_head osnoise_instances;
> @@ -159,7 +160,7 @@ static void osnoise_unregister_instance(struct trace_array *tr)
> if (!found)
> return;
>
> - kvfree_rcu(inst);
> + kvfree_rcu(inst, rcu);
> }
>
> /*
> diff --git a/kernel/trace/trace_probe.c b/kernel/trace/trace_probe.c
> index 20d0c4a97633..ef5fafb40c76 100644
> --- a/kernel/trace/trace_probe.c
> +++ b/kernel/trace/trace_probe.c
> @@ -1172,7 +1172,7 @@ int trace_probe_remove_file(struct trace_probe *tp,
> return -ENOENT;
>
> list_del_rcu(&link->list);
> - kvfree_rcu(link);
> + kvfree_rcu(link, rcu);
>
> if (list_empty(&tp->event->files))
> trace_probe_clear_flag(tp, TP_FLAG_TRACE);
> diff --git a/kernel/trace/trace_probe.h b/kernel/trace/trace_probe.h
> index ef8ed3b65d05..e6037752dcf0 100644
> --- a/kernel/trace/trace_probe.h
> +++ b/kernel/trace/trace_probe.h
> @@ -256,6 +256,7 @@ struct trace_probe {
> struct event_file_link {
> struct trace_event_file *file;
> struct list_head list;
> + struct rcu_head rcu;
> };
>
> static inline bool trace_probe_test_flag(struct trace_probe *tp,
>
struct foo_a {
int a;
int b;
};
your obj size is 8 byte
struct foo_b {
struct rcu_head rcu;
int a;
int b;
};
now it becomes 16 + 8 = 24 bytes. In reallity a foo_b object
will be 32 bytes since there is no slab for 24 bytes:
<snip>
kmalloc-32 19840 19840 32 128 1 : tunables 0 0 0 : slabdata 155 155 0
kmalloc-16 28857 28928 16 256 1 : tunables 0 0 0 : slabdata 113 113 0
kmalloc-8 37376 37376 8 512 1 : tunables 0 0 0 : slabdata 73 73 0
<snip>
if we allocate 512 objects of foo_a it would be 4096 bytes
in case of foo_b it is 24 * 512 = 12228 bytes.
single argument will give you 4096 + 512 * 8 = 8192 bytes
int terms of memory consumtion.
And double argument will not give you better performance comparing
with a single argument.
So it depends on what you want to achieve by that patch.
--
Uladzislau Rezki
next prev parent reply other threads:[~2023-03-16 8:17 UTC|newest]
Thread overview: 77+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-01 15:08 [PATCH 00/13] Rename k[v]free_rcu() single argument to k[v]free_rcu_mightsleep() Uladzislau Rezki (Sony)
2023-02-01 15:08 ` [PATCH 01/13] rcu/kvfree: Add kvfree_rcu_mightsleep() and kfree_rcu_mightsleep() Uladzislau Rezki (Sony)
2023-02-02 7:54 ` Zhuo, Qiuxu
2023-02-02 15:07 ` Paul E. McKenney
2023-02-01 15:08 ` [PATCH 02/13] drbd: Rename kvfree_rcu() to kvfree_rcu_mightsleep() Uladzislau Rezki (Sony)
2023-03-09 13:39 ` Uladzislau Rezki
2023-02-01 15:08 ` [PATCH 03/13] misc: vmw_vmci: " Uladzislau Rezki (Sony)
2023-03-09 13:41 ` Uladzislau Rezki
2023-03-09 14:36 ` Vishnu Dasa
2023-02-01 15:08 ` [PATCH 04/13] tracing: " Uladzislau Rezki (Sony)
2023-03-09 13:45 ` Uladzislau Rezki
2023-03-15 22:36 ` Steven Rostedt
2023-03-15 23:19 ` Jens Axboe
2023-03-16 0:37 ` Paul E. McKenney
2023-03-16 2:23 ` Steven Rostedt
2023-03-16 3:44 ` Paul E. McKenney
2023-03-16 4:16 ` Joel Fernandes
2023-03-16 12:14 ` Steven Rostedt
2023-03-16 14:56 ` Paul E. McKenney
2023-03-16 8:16 ` Uladzislau Rezki [this message]
2023-03-16 13:56 ` Steven Rostedt
2023-03-16 15:05 ` Uladzislau Rezki
2023-03-17 9:05 ` Uladzislau Rezki
2023-03-16 15:12 ` Paul E. McKenney
2023-03-16 17:54 ` Paul E. McKenney
2023-03-16 17:57 ` Uladzislau Rezki
2023-03-16 18:01 ` Joel Fernandes
2023-03-18 16:11 ` Steven Rostedt
2023-03-22 23:10 ` Joel Fernandes
2023-02-01 15:08 ` [PATCH 05/13] lib/test_vmalloc.c: " Uladzislau Rezki (Sony)
2023-02-01 15:08 ` [PATCH 06/13] net/sysctl: " Uladzislau Rezki (Sony)
2023-03-09 13:48 ` Uladzislau Rezki
2023-03-09 13:49 ` Uladzislau Rezki
2023-02-01 15:08 ` [PATCH 07/13] RDMA/rxe: Rename kfree_rcu() to kfree_rcu_mightsleep() Uladzislau Rezki (Sony)
2023-03-09 13:48 ` Uladzislau Rezki
2023-03-09 14:13 ` Uladzislau Rezki
2023-03-10 0:55 ` Joel Fernandes
2023-03-13 19:43 ` Bob Pearson
2023-03-15 11:50 ` Joel Fernandes
2023-03-15 18:07 ` Bob Pearson
2023-03-14 6:31 ` Zhu Yanjun
2023-02-01 15:08 ` [PATCH 08/13] net/mlx5: " Uladzislau Rezki (Sony)
2023-03-09 13:47 ` Uladzislau Rezki
2023-02-01 15:08 ` [PATCH 09/13] ext4/super: " Uladzislau Rezki (Sony)
2023-03-09 13:43 ` Uladzislau Rezki
2023-02-01 19:12 ` [PATCH 00/13] Rename k[v]free_rcu() single argument to k[v]free_rcu_mightsleep() Paul E. McKenney
2023-02-02 15:54 ` Uladzislau Rezki
2023-02-02 16:35 ` Paul E. McKenney
2023-02-23 12:45 ` Frederic Weisbecker
2023-02-23 14:29 ` Zhuo, Qiuxu
2023-02-23 15:54 ` Paul E. McKenney
2023-02-23 16:21 ` Julian Anastasov
2023-02-23 17:14 ` Paul E. McKenney
2023-02-23 17:36 ` Pablo Neira Ayuso
2023-02-23 18:21 ` Paul E. McKenney
2023-02-23 14:57 ` Jens Axboe
2023-02-23 18:31 ` Paul E. McKenney
2023-02-23 19:36 ` Jens Axboe
2023-02-23 19:47 ` Paul E. McKenney
2023-02-23 19:57 ` Jens Axboe
2023-03-15 19:14 ` Steven Rostedt
2023-03-15 19:16 ` Jens Axboe
2023-03-15 19:25 ` Uladzislau Rezki
2023-03-15 19:34 ` Steven Rostedt
2023-03-15 19:57 ` Joel Fernandes
2023-03-15 20:28 ` Steven Rostedt
2023-03-15 21:07 ` Uladzislau Rezki
2023-03-15 21:14 ` Uladzislau Rezki
2023-03-15 22:08 ` Joel Fernandes
2023-03-15 22:26 ` Steven Rostedt
2023-03-16 2:13 ` Joel Fernandes
2023-03-16 2:50 ` Steven Rostedt
2023-03-16 5:01 ` Joel Fernandes
2023-03-16 1:25 ` Theodore Ts'o
2023-03-16 2:15 ` Steven Rostedt
2023-03-16 2:52 ` Paul E. McKenney
2023-03-16 0:42 ` Theodore Ts'o
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=ZBLQZSm+SuazEODN@pc636 \
--to=urezki@gmail.com \
--cc=axboe@kernel.dk \
--cc=bryantan@vmware.com \
--cc=edumazet@google.com \
--cc=ja@ssi.bg \
--cc=lariel@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=oleksiy.avramchenko@sony.com \
--cc=paulmck@kernel.org \
--cc=philipp.reisner@linbit.com \
--cc=rcu@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=rpearsonhpe@gmail.com \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.