Re: [RFC PATCH v v2 0/4] avoid the extra atomic on a ref when closing a fd
From: Mateusz Guzik
Date: Wed Mar 05 2025 - 07:42:42 EST
On Wed, Mar 5, 2025 at 11:38 AM Christian Brauner <brauner@xxxxxxxxxx> wrote:
>
> On Tue, Mar 04, 2025 at 07:35:02PM +0100, Mateusz Guzik wrote:
> > The stock kernel transitioning the file to no refs held penalizes the
> > caller with an extra atomic to block any increments.
> >
> > For cases where the file is highly likely to be going away this is
> > easily avoidable.
> >
> > In the open+close case the win is very modest because of the following
> > problems:
> > - kmem and memcg having terrible performance
>
> I thought that was going to be addressed by Vlastimil, i.e., the mm guys
> to provide a new memcg api.
afaics this is for kmem only, no memcg support.
There is an old patch which sped up memcg, but got reverted and it is
on the table to bring it back, but Vlastimil is dragging his foot.
> > vast majority of last fputs are from remove_vma. I think that code wants
> > to be patched to batch them (as in something like fput_many should be
> > added -- something for later).
>
> We used to have that for io_uring and got rid of it. The less fput()
> primitives the better tbh. But let's see.
>
I would say a _many (or whatever) variant is pretty idiomatic, but I'm
not going to insist. This is a side remark to the patchset.
--
Mateusz Guzik <mjguzik gmail.com>