[lkml]   [2019]   [Jun]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 09/12] xfs: refactor the ioend merging code

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

 \ /
  Last update: 2019-06-25 14:42    [W:0.068 / U:3.792 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site