[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190625101445.GK1462@lst.de>
Date: Tue, 25 Jun 2019 12:14:45 +0200
From: Christoph Hellwig <hch@....de>
To: Nikolay Borisov <nborisov@...e.com>
Cc: Christoph Hellwig <hch@....de>,
"Darrick J . Wong" <darrick.wong@...cle.com>,
Damien Le Moal <Damien.LeMoal@....com>,
Andreas Gruenbacher <agruenba@...hat.com>,
linux-xfs@...r.kernel.org, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 09/12] xfs: refactor the ioend merging code
On Mon, Jun 24, 2019 at 07:06:22PM +0300, Nikolay Borisov wrote:
> > +{
> > + struct list_head tmp;
> > +
> > + list_replace_init(&ioend->io_list, &tmp);
> > + xfs_destroy_ioend(ioend, error);
> > + while ((ioend = list_pop(&tmp, struct xfs_ioend, io_list)))
> > + xfs_destroy_ioend(ioend, error);
>
> nit: I'd prefer if the list_pop patch is right before this one since
> this is the first user of it.
I try to keep generic infrastructure first instead of interveawing
it with subystem-specific patches.
> Additionally, I don't think list_pop is
> really a net-negative win
What is a "net-negative win" ?
> in comparison to list_for_each_entry_safe
> here. In fact this "delete the list" would seems more idiomatic if
> implemented via list_for_each_entry_safe
I disagree. The for_each loops require an additional next iterator,
and also don't clearly express what is going on, but require additional
spotting of the list_del.
Powered by blists - more mailing lists