| Message ID | 20230710064705.1847287-1-chengming.zhou@linux.dev (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [1/2] blk-flush: fix rq->flush.seq for post-flush requests | expand |
On Mon, Jul 10, 2023 at 02:47:04PM +0800, chengming.zhou@linux.dev wrote: > From: Chengming Zhou <zhouchengming@bytedance.com> > > If the policy == (REQ_FSEQ_DATA | REQ_FSEQ_POSTFLUSH), it means that the > data sequence and post-flush sequence need to be done for this request. > > The rq->flush.seq should record what sequences have been done (or don't > need to be done). So in this case, pre-flush doesn't need to be done, > we should init rq->flush.seq to REQ_FSEQ_PREFLUSH not REQ_FSEQ_POSTFLUSH. > > Of course, this doesn't cause any problem in fact, since pre-flush and > post-flush sequence do the same thing for now. I wonder if it really doesn't cause any problems, but the change for sure looks good: Reviewed-by: Christoph Hellwig <hch@lst.de> It should probably go before your other flush optimizations and maybe grow a fixes tag.
On 2023/7/10 21:30, Christoph Hellwig wrote: > On Mon, Jul 10, 2023 at 02:47:04PM +0800, chengming.zhou@linux.dev wrote: >> From: Chengming Zhou <zhouchengming@bytedance.com> >> >> If the policy == (REQ_FSEQ_DATA | REQ_FSEQ_POSTFLUSH), it means that the >> data sequence and post-flush sequence need to be done for this request. >> >> The rq->flush.seq should record what sequences have been done (or don't >> need to be done). So in this case, pre-flush doesn't need to be done, >> we should init rq->flush.seq to REQ_FSEQ_PREFLUSH not REQ_FSEQ_POSTFLUSH. >> >> Of course, this doesn't cause any problem in fact, since pre-flush and >> post-flush sequence do the same thing for now. > > I wonder if it really doesn't cause any problems, but the change for > sure looks good: > > Reviewed-by: Christoph Hellwig <hch@lst.de> > > It should probably go before your other flush optimizations and maybe > grow a fixes tag. Ok, will add a Fixes tag and send it as a separate patch since it's a bug fix. Thanks.
On 2023/7/11 19:06, Chengming Zhou wrote: > On 2023/7/10 21:30, Christoph Hellwig wrote: >> On Mon, Jul 10, 2023 at 02:47:04PM +0800, chengming.zhou@linux.dev wrote: >>> From: Chengming Zhou <zhouchengming@bytedance.com> >>> >>> If the policy == (REQ_FSEQ_DATA | REQ_FSEQ_POSTFLUSH), it means that the >>> data sequence and post-flush sequence need to be done for this request. >>> >>> The rq->flush.seq should record what sequences have been done (or don't >>> need to be done). So in this case, pre-flush doesn't need to be done, >>> we should init rq->flush.seq to REQ_FSEQ_PREFLUSH not REQ_FSEQ_POSTFLUSH. >>> >>> Of course, this doesn't cause any problem in fact, since pre-flush and >>> post-flush sequence do the same thing for now. >> >> I wonder if it really doesn't cause any problems, but the change for >> sure looks good: >> >> Reviewed-by: Christoph Hellwig <hch@lst.de> >> >> It should probably go before your other flush optimizations and maybe >> grow a fixes tag. > > Ok, will add a Fixes tag and send it as a separate patch since it's a bug fix. > Well, I should put it in that series before other flush optimizations instead.
On Tue, Jul 11, 2023 at 07:06:20PM +0800, Chengming Zhou wrote:
> Ok, will add a Fixes tag and send it as a separate patch since it's a bug fix.
Btw, it's probably not worth resending patch 2 until we've figured out
and dealt with the SATA flush regression that Chuck reported.
On 2023/7/11 19:31, Christoph Hellwig wrote: > On Tue, Jul 11, 2023 at 07:06:20PM +0800, Chengming Zhou wrote: >> Ok, will add a Fixes tag and send it as a separate patch since it's a bug fix. > > Btw, it's probably not worth resending patch 2 until we've figured out > and dealt with the SATA flush regression that Chuck reported. Ok, I will not resend patch 2. As for the patch 1, should I resend it as a separate patch or just put it in that series [1] before other flush optimizations ? I search on the block mail list, find the issue [2] you mentioned, will look into it too. [1] https://lore.kernel.org/lkml/20230707093722.1338589-1-chengming.zhou@linux.dev/ [2] https://lore.kernel.org/linux-block/7A57C7AE-A51A-4254-888B-FE15CA21F9E9@oracle.com/
On Tue, Jul 11, 2023 at 07:52:11PM +0800, Chengming Zhou wrote: > On 2023/7/11 19:31, Christoph Hellwig wrote: > > On Tue, Jul 11, 2023 at 07:06:20PM +0800, Chengming Zhou wrote: > >> Ok, will add a Fixes tag and send it as a separate patch since it's a bug fix. > > > > Btw, it's probably not worth resending patch 2 until we've figured out > > and dealt with the SATA flush regression that Chuck reported. > > Ok, I will not resend patch 2. As for the patch 1, should I resend it as a separate patch > or just put it in that series [1] before other flush optimizations ? I'd wait a bit for debugging the regression. For the worst case we'll have to revert the patch, which currently can be done cleanly, but can't be with that patch.
diff --git a/block/blk-flush.c b/block/blk-flush.c index 4826d2d61a23..094a6adb2718 100644 --- a/block/blk-flush.c +++ b/block/blk-flush.c @@ -448,7 +448,7 @@ bool blk_insert_flush(struct request *rq) * the post flush, and then just pass the command on. */ blk_rq_init_flush(rq); - rq->flush.seq |= REQ_FSEQ_POSTFLUSH; + rq->flush.seq |= REQ_FSEQ_PREFLUSH; spin_lock_irq(&fq->mq_flush_lock); fq->flush_data_in_flight++; spin_unlock_irq(&fq->mq_flush_lock);