All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chengming Zhou <chengming.zhou@linux.dev>
To: Ming Lei <ming.lei@redhat.com>
Cc: axboe@kernel.dk, tj@kernel.org, hch@lst.de,
	linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
	zhouchengming@bytedance.com
Subject: Re: [PATCH 2/4] blk-flush: count inflight flush_data requests
Date: Wed, 28 Jun 2023 12:55:49 +0800	[thread overview]
Message-ID: <490fd0d8-c0b3-cc26-c658-da35d52b6b56@linux.dev> (raw)
In-Reply-To: <ZJuzYMeVhP5cthbC@ovpn-8-21.pek2.redhat.com>

On 2023/6/28 12:13, Ming Lei wrote:
> On Tue, Jun 27, 2023 at 08:08:52PM +0800, chengming.zhou@linux.dev wrote:
>> From: Chengming Zhou <zhouchengming@bytedance.com>
>>
>> The flush state machine use a double list to link all inflight
>> flush_data requests, to avoid issuing separate post-flushes for
>> these flush_data requests which shared PREFLUSH.
>>
>> So we can't reuse rq->queuelist, this is why we need rq->flush.list
>>
>> In preparation of the next patch that reuse rq->queuelist for flush
>> state machine, we change the double linked list to a u64 counter,
>> which count all inflight flush_data requests.
>>
>> This is ok since we only need to know if there is any inflight
>> flush_data request, so a u64 counter is good. The only problem I can
>> think of is that u64 counter may overflow, which should be unlikely happen.
> 
> It won't overflow, q->nr_requests is 'unsigned long', which should have
> been limited to one more reasonable value, such as 2 * BLK_MQ_MAX_DEPTH, so
> u16 should be big enough in theory.

Ah, right. q->nr_requests is 'unsigned long' and q->queue_depth is 'unsigned int',
so 'unsigned long' counter here won't overflow.

Should I change it to smaller 'unsigned short' or just leave it as 'unsigned long' ?
(Now the size of struct blk_flush_queue is exactly 64 bytes)

Thanks.

> 
>>
>> Signed-off-by: Chengming Zhou <zhouchengming@bytedance.com>
>> ---
>>  block/blk-flush.c | 9 +++++----
>>  block/blk.h       | 5 ++---
>>  2 files changed, 7 insertions(+), 7 deletions(-)
>>
>> diff --git a/block/blk-flush.c b/block/blk-flush.c
>> index dba392cf22be..bb7adfc2a5da 100644
>> --- a/block/blk-flush.c
>> +++ b/block/blk-flush.c
>> @@ -187,7 +187,8 @@ static void blk_flush_complete_seq(struct request *rq,
>>  		break;
>>  
>>  	case REQ_FSEQ_DATA:
>> -		list_move_tail(&rq->flush.list, &fq->flush_data_in_flight);
>> +		list_del_init(&rq->flush.list);
>> +		fq->flush_data_in_flight++;
>>  		spin_lock(&q->requeue_lock);
>>  		list_add_tail(&rq->queuelist, &q->flush_list);
>>  		spin_unlock(&q->requeue_lock);
>> @@ -299,7 +300,7 @@ static void blk_kick_flush(struct request_queue *q, struct blk_flush_queue *fq,
>>  		return;
>>  
>>  	/* C2 and C3 */
>> -	if (!list_empty(&fq->flush_data_in_flight) &&
>> +	if (fq->flush_data_in_flight &&
>>  	    time_before(jiffies,
>>  			fq->flush_pending_since + FLUSH_PENDING_TIMEOUT))
>>  		return;
>> @@ -374,6 +375,7 @@ static enum rq_end_io_ret mq_flush_data_end_io(struct request *rq,
>>  	 * the comment in flush_end_io().
>>  	 */
>>  	spin_lock_irqsave(&fq->mq_flush_lock, flags);
>> +	fq->flush_data_in_flight--;
>>  	blk_flush_complete_seq(rq, fq, REQ_FSEQ_DATA, error);
>>  	spin_unlock_irqrestore(&fq->mq_flush_lock, flags);
>>  
>> @@ -445,7 +447,7 @@ bool blk_insert_flush(struct request *rq)
>>  		blk_rq_init_flush(rq);
>>  		rq->flush.seq |= REQ_FSEQ_POSTFLUSH;
>>  		spin_lock_irq(&fq->mq_flush_lock);
>> -		list_move_tail(&rq->flush.list, &fq->flush_data_in_flight);
>> +		fq->flush_data_in_flight++;
>>  		spin_unlock_irq(&fq->mq_flush_lock);
>>  		return false;
>>  	default:
>> @@ -496,7 +498,6 @@ struct blk_flush_queue *blk_alloc_flush_queue(int node, int cmd_size,
>>  
>>  	INIT_LIST_HEAD(&fq->flush_queue[0]);
>>  	INIT_LIST_HEAD(&fq->flush_queue[1]);
>> -	INIT_LIST_HEAD(&fq->flush_data_in_flight);
>>  
>>  	return fq;
>>  
>> diff --git a/block/blk.h b/block/blk.h
>> index 608c5dcc516b..686712e13835 100644
>> --- a/block/blk.h
>> +++ b/block/blk.h
>> @@ -15,15 +15,14 @@ struct elevator_type;
>>  extern struct dentry *blk_debugfs_root;
>>  
>>  struct blk_flush_queue {
>> +	spinlock_t		mq_flush_lock;
>>  	unsigned int		flush_pending_idx:1;
>>  	unsigned int		flush_running_idx:1;
>>  	blk_status_t 		rq_status;
>>  	unsigned long		flush_pending_since;
>>  	struct list_head	flush_queue[2];
>> -	struct list_head	flush_data_in_flight;
>> +	unsigned long		flush_data_in_flight;
>>  	struct request		*flush_rq;
>> -
>> -	spinlock_t		mq_flush_lock;
>>  };
> 
> The part of replacing inflight data rq list with counter looks fine.
> 
> Thanks,
> Ming
> 

  reply	other threads:[~2023-06-28  8:22 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-27 12:08 [PATCH 0/4] blk-mq: optimize the size of struct request chengming.zhou
2023-06-27 12:08 ` [PATCH 1/4] blk-mq: use percpu csd to remote complete instead of per-rq csd chengming.zhou
2023-06-28  2:20   ` Ming Lei
2023-06-28  3:28     ` Chengming Zhou
2023-06-28  4:50       ` Ming Lei
2023-06-28  6:43         ` Chengming Zhou
2023-06-27 12:08 ` [PATCH 2/4] blk-flush: count inflight flush_data requests chengming.zhou
2023-06-28  4:13   ` Ming Lei
2023-06-28  4:55     ` Chengming Zhou [this message]
2023-06-28  7:22       ` Ming Lei
2023-06-28 12:55         ` Chengming Zhou
2023-06-27 12:08 ` [PATCH 3/4] blk-flush: reuse rq queuelist in flush state machine chengming.zhou
2023-06-27 12:08 ` [PATCH 4/4] blk-mq: delete unused completion_data in struct request chengming.zhou

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=490fd0d8-c0b3-cc26-c658-da35d52b6b56@linux.dev \
    --to=chengming.zhou@linux.dev \
    --cc=axboe@kernel.dk \
    --cc=hch@lst.de \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ming.lei@redhat.com \
    --cc=tj@kernel.org \
    --cc=zhouchengming@bytedance.com \
    /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.