[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAL3q7H54GbT5+bnN87U6i2EUOiYUpQt5m98fxPEPC=N+ALOUCw@mail.gmail.com>
Date: Thu, 17 Apr 2025 15:36:17 +0100
From: Filipe Manana <fdmanana@...nel.org>
To: 李扬韬 <frank.li@...o.com>
Cc: "dsterba@...e.cz" <dsterba@...e.cz>, Sun YangKai <sunk67188@...il.com>, "clm@...com" <clm@...com>,
"dsterba@...e.com" <dsterba@...e.com>, "josef@...icpanda.com" <josef@...icpanda.com>,
"linux-btrfs@...r.kernel.org" <linux-btrfs@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "neelx@...e.com" <neelx@...e.com>
Subject: Re: [PATCH 1/3] btrfs: get rid of path allocation in btrfs_del_inode_extref()
On Thu, Apr 17, 2025 at 3:15 PM 李扬韬 <frank.li@...o.com> wrote:
>
> > Honestly I don't like adding yet another function to do such "reset" thing.
> >
> > Leaving path->skip_release_on_error is perfectly fine in this scenario.
> > If that bothers anyone so much, just set path->skip_release_on_error to 0 after calling btrfs_release_path() and before passing the path to btrfs_insert_inode_extref().
> >
> > This is the sort of optimization that is not worth spending this much time and adding new APIs - freeing and allocating a path shortly after is almost always fast as we're using a slab, plus this is a rarely hit use case - having to use extrefs, meaning we have a very large number of inode refs.
>
> I am fine to add btrfs_reset_path or just clear path->skip_release_on_error.
For god's sake, just keep it simple - either do nothing or set
path->skip_release_on_error to 0.
>
> David, what do you think?
>
> Thx,
> Yangtao
Powered by blists - more mailing lists