lkml.org 
[lkml]   [2019]   [Jun]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 09/12] xfs: refactor the ioend merging code
    On Tue, Jun 25, 2019 at 03:42:20PM +0300, Nikolay Borisov wrote:
    >
    >
    > On 25.06.19 г. 13:14 ч., Christoph Hellwig wrote:
    > > 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" ?
    >
    > What I meant was 'net-positive win', in terms of making the code more
    > readable or optimised.
    >
    > >
    > >> 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.
    >
    > That is of course your opinion. At the very least we can agree to disagree.
    >
    > What I'm worried about, though, is now you've essentially introduced a
    > new idiom to dispose of lists, which is used only in your code. If it
    > doesn't become more widespread and gradually start replacing current
    > list_for_each_entry_safe usage then you would have increased the public
    > list interface to cater for one specific use case, just because it seems
    > more natural to you. I guess only time will show whether it makes sense
    > to have list_pop_entry

    I for one would love to replace all the opencoded "walk a list and drop
    each entry before we move on" code in fs/xfs/scrub/ with list_pop_entry.
    Quickly scanning fs/xfs/, there seem to be a couple dozen places where
    we could probably do that too.

    --D

    \
     
     \ /
      Last update: 2019-06-25 16:46    [W:2.509 / U:0.304 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site