All of lore.kernel.org
 help / color / mirror / Atom feed
From: Coly Li <colyli@suse.de>
To: Jens Axboe <axboe@kernel.dk>
Cc: linux-bcache@vger.kernel.org, linux-block@vger.kernel.org
Subject: Re: [PATCH 0/4] bcache patches for Linux v5.19 (1st wave)
Date: Mon, 23 May 2022 14:26:28 +0800	[thread overview]
Message-ID: <9c3fddec-1741-872f-1cdb-b44316e2ff64@suse.de> (raw)
In-Reply-To: <ece7e00e-5d03-41c0-4013-75809958e9d7@kernel.dk>

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.

Thanks in advance.


Coly Li


  reply	other threads:[~2022-05-23  7:33 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-22 17:07 [PATCH 0/4] bcache patches for Linux v5.19 (1st wave) Coly Li
2022-05-22 17:07 ` [PATCH 1/4] bcache: improve multithreaded bch_btree_check() Coly Li
2022-05-22 17:07 ` [PATCH 2/4] bcache: improve multithreaded bch_sectors_dirty_init() Coly Li
2022-05-22 17:07 ` [PATCH 3/4] bcache: remove incremental dirty sector counting for bch_sectors_dirty_init() Coly Li
2022-05-22 17:07 ` [PATCH 4/4] bcache: avoid journal no-space deadlock by reserving 1 journal bucket Coly Li
2022-05-22 17:43 ` [PATCH 0/4] bcache patches for Linux v5.19 (1st wave) Jens Axboe
2022-05-23  6:26   ` Coly Li [this message]
2022-05-23 12:34     ` Jens Axboe
2022-05-22 21:40 ` Jens Axboe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9c3fddec-1741-872f-1cdb-b44316e2ff64@suse.de \
    --to=colyli@suse.de \
    --cc=axboe@kernel.dk \
    --cc=linux-bcache@vger.kernel.org \
    --cc=linux-block@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.