[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e4d47000-f89c-a135-ae58-011f0e9cc39e@grimberg.me>
Date: Fri, 8 May 2020 14:35:35 -0700
From: Sagi Grimberg <sagi@...mberg.me>
To: Christoph Hellwig <hch@...radead.org>,
Baolin Wang <baolin.wang7@...il.com>
Cc: axboe@...nel.dk, ulf.hansson@...aro.org, adrian.hunter@...el.com,
arnd@...db.de, linus.walleij@...aro.org, paolo.valente@...aro.org,
ming.lei@...hat.com, orsonzhai@...il.com, zhang.lyra@...il.com,
linux-mmc@...r.kernel.org, linux-block@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v2 1/7] block: Extand commit_rqs() to do batch
processing
>> diff --git a/include/linux/blk-mq.h b/include/linux/blk-mq.h
>> index f389d7c724bd..6a20f8e8eb85 100644
>> --- a/include/linux/blk-mq.h
>> +++ b/include/linux/blk-mq.h
>> @@ -391,6 +391,7 @@ struct blk_mq_ops {
>> enum {
>> BLK_MQ_F_SHOULD_MERGE = 1 << 0,
>> BLK_MQ_F_TAG_SHARED = 1 << 1,
>> + BLK_MQ_F_FORCE_COMMIT_RQS = 1 << 3,
>
> Maybe BLK_MQ_F_ALWAYS_COMMIT might be a better name? Also this
> flag (just like the existing ones..) could really use a comment
> explaining it.
Would it make sense to elevate this flag to a request_queue flag
(QUEUE_FLAG_ALWAYS_COMMIT)?
I'm thinking of a possibility that an I/O scheduler may be used
to activate this functionality rather than having the driver set
it necessarily...
Powered by blists - more mailing lists