[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEXW_YSm_uvuEJ5C27Rw8NRPNzhNWNg=Te3D9BVhc4ucb4tqqw@mail.gmail.com>
Date: Wed, 22 Jan 2025 11:47:05 -0500
From: Joel Fernandes <joel@...lfernandes.org>
To: Vlastimil Babka <vbabka@...e.cz>
Cc: paulmck@...nel.org, Uladzislau Rezki <urezki@...il.com>, linux-mm@...ck.org,
Andrew Morton <akpm@...ux-foundation.org>, RCU <rcu@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>, Christoph Lameter <cl@...ux.com>,
Pekka Enberg <penberg@...nel.org>, David Rientjes <rientjes@...gle.com>,
Joonsoo Kim <iamjoonsoo.kim@....com>, Roman Gushchin <roman.gushchin@...ux.dev>,
Hyeonggon Yoo <42.hyeyoo@...il.com>, Oleksiy Avramchenko <oleksiy.avramchenko@...y.com>
Subject: Re: [PATCH v2 0/5] Move kvfree_rcu() into SLAB (v2)
On Wed, Jan 22, 2025 at 11:43 AM Vlastimil Babka <vbabka@...e.cz> wrote:
[...]
> > __is_kvfree_rcu_offset() and its usage from Tiny. Granted, there is
> > the overhead of function calling, but I highly doubt that it is going
> > to be a bottleneck, considering that the __is_kvfree_rcu_offset() path
> > is a kfree slow-path. I feel in the long run, this will also be more
> > maintainable.
> >
> > Or is there a reason other than the theoretical function call overhead
> > why this may not work?
>
> My concern was about the overhead of calculating the pointer to the object
> starting address, but it's just some arithmetics, so it should be
> negligible. So I'm prototyping this approach now. Thanks all.
Ah, that's a valid point. Looking forward to reviewing the patch and
hope it works out!
thanks,
- Joel
Powered by blists - more mailing lists