Re: [PATCH 0/4] bcache patches for Linux v5.19 (1st wave)

[Jens Axboe <axboe@kernel.dk>]

On 5/23/22 12:26 AM, Coly Li wrote:
> On 5/23/22 1:43 AM, Jens Axboe wrote:
>> On 5/22/22 11:07 AM, Coly Li wrote:
>>> Hi Jens,
>>>
>>> The bcache has 4 patches for Linux v5.19 merge window, all from me.
>>> - The first 2 patches are code clean up and potential bug fixes for
>>> multi- threaded btree nodes check (for cache device) and dirty sectors
>>> counting (for backing device), although no report from mailing list for
>>> them, it is good to have the fixes.
>>> - The 3rd patch removes incremental dirty sectors counting because it
>>> is conflicted with multithreaded dirty sectors counting and the latter
>>> one is 10x times faster.
>>> - The last patch fixes a journal no-space deadlock during cache device
>>> registration, it always reserves one journal bucket and only uses it
>>> in registration time, so the no-spance condition won't happen anymore.
>>>
>>> There are still 2 fixes are still under the long time I/O pressure
>>> testing, once they are accomplished, I will submit to you in later
>>> RC cycles.
>>>
>>> Please take them, and thanks in advance.
>> It's late for sending in that stuff, now I have to do a round 2 or
>> your patches would get zero time in linux-next. Please send patches
>> a week in advance at least, not on the day of release...
>>
> Hi Jens,
> 
> This time the situation was awkward, indeed I didn't expect I can
> submit the fix in this merge window, but just around 1 week before I
> found the difficult was from influence by other depending issues.
> After fixed all of them and do I/O pressure testing for 24x2 hours, it
> comes to such close day to the merge window.
> 
> My confusion was, it was very close to the merge window so maybe I
> should submit them in next merge window (5.20), but this series were
> bug fixes which should go into mainline earlier. It seems neither
> option was proper, so I chose the first one...
> 
> Could you give me a hint, what is the proper way that I should do for
> such situation? Then I will try to follow that and avoid adding more
> workload to you.

It would help if the submission came with an explanation of why they are
being submitted so late, as I really do expect it to happen around -rc7
time. Sometimes it's just because people are a bit lazy getting changes
submitted, and then do it at that last minute. That makes me a bit
annoyed. And other times there are totally legitimate reasons for why
they are being submitted late, like your explanation above.

It really depends on the scope of the changes, too. Simple fixes are
obviously fair game at any time.

-- 
Jens Axboe