linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Damien Le Moal <dlemoal@kernel.org>
To: Bart Van Assche <bvanassche@acm.org>, Jens Axboe <axboe@kernel.dk>
Cc: linux-block@vger.kernel.org, linux-scsi@vger.kernel.org,
	linux-fsdevel@vger.kernel.org,
	"Martin K . Petersen" <martin.petersen@oracle.com>,
	Christoph Hellwig <hch@lst.de>,
	Niklas Cassel <Niklas.Cassel@wdc.com>,
	Avri Altman <Avri.Altman@wdc.com>, Bean Huo <huobean@gmail.com>,
	Daejun Park <daejun7.park@samsung.com>,
	Hannes Reinecke <hare@suse.de>
Subject: Re: [PATCH v2 03/15] block: Support data lifetime in the I/O priority bitfield
Date: Thu, 12 Oct 2023 10:02:07 +0900	[thread overview]
Message-ID: <447f3095-66cb-417b-b48c-90005d37b5d3@kernel.org> (raw)
In-Reply-To: <b0b015bf-0a27-4e89-950a-597b9fed20fb@acm.org>

On 10/12/23 05:51, Bart Van Assche wrote:
> On 10/6/23 11:07, Bart Van Assche wrote:
>> On 10/6/23 01:19, Damien Le Moal wrote:
>>> Your change seem to assume that it makes sense to be able to combine CDL with
>>> lifetime hints. But does it really ? CDL is of dubious value for solid state
>>> media and as far as I know, UFS world has not expressed interest. Conversely,
>>> data lifetime hints do not make much sense for spin rust media where CDL is
>>> important. So I would say that the combination of CDL and lifetime hints is of
>>> dubious value.
>>>
>>> Given this, why not simply define the 64 possible lifetime values as plain hint
>>> values (8 to 71, following 1 to 7 for CDL) ?
>>>
>>> The other question here if you really want to keep the bit separation approach
>>> is: do we really need up to 64 different lifetime hints ? While the scsi
>>> standard allows that much, does this many different lifetime make sense in
>>> practice ? Can we ever think of a usecase that needs more than say 8 different
>>> liftimes (3 bits) ? If you limit the number of possible lifetime hints to 8,
>>> then we can keep 4 bits unused in the hint field for future features.
>>
>> Hi Damien,
>>
>> Not supporting CDL for solid state media and supporting eight different
>> lifetime values sounds good to me. Is this perhaps what you had in mind?
>>
>> Thanks,
>>
>> Bart.
>>
>> --- a/include/uapi/linux/ioprio.h
>> +++ b/include/uapi/linux/ioprio.h
>> @@ -100,6 +100,14 @@ enum {
>>          IOPRIO_HINT_DEV_DURATION_LIMIT_5 = 5,
>>          IOPRIO_HINT_DEV_DURATION_LIMIT_6 = 6,
>>          IOPRIO_HINT_DEV_DURATION_LIMIT_7 = 7,
>> +       IOPRIO_HINT_DATA_LIFE_TIME_0 = 8,
>> +       IOPRIO_HINT_DATA_LIFE_TIME_1 = 9,
>> +       IOPRIO_HINT_DATA_LIFE_TIME_2 = 10,
>> +       IOPRIO_HINT_DATA_LIFE_TIME_3 = 11,
>> +       IOPRIO_HINT_DATA_LIFE_TIME_4 = 12,
>> +       IOPRIO_HINT_DATA_LIFE_TIME_5 = 13,
>> +       IOPRIO_HINT_DATA_LIFE_TIME_6 = 14,
>> +       IOPRIO_HINT_DATA_LIFE_TIME_7 = 15,
>>   };
> 
> (replying to my own e-mail)
> 
> Hi Damien,
> 
> Does the above look good to you?

Yes, it is what I was thinking of and I think it looks much better (and
simpler) than coding with different bits. However, I think this is acceptable
only if everyone agrees that combining CDL and lifetime (and potentially other
hints) is not a sensible thing to do. I stated that my thinking is that CDL is
more geared toward rotating media while lifetime is more suitable for solid
state media. But does everyone agree ?

Some have stated interest in CDL in NVMe-oF context, which could imply that
combining CDL and lifetime may be something useful to do in that space...

Getting more opinions about this would be nice. If we do not get any, I would
say that we should go with this.

-- 
Damien Le Moal
Western Digital Research


  reply	other threads:[~2023-10-12  1:02 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-05 19:40 [PATCH v2 00/15] Pass data temperature information to UFS devices Bart Van Assche
2023-10-05 19:40 ` [PATCH v2 01/15] block: Make bio_set_ioprio() modify fewer bio->bi_ioprio bits Bart Van Assche
2023-10-06  6:28   ` Kanchan Joshi
2023-10-06 18:20     ` Bart Van Assche
2023-10-10  5:22   ` Kanchan Joshi
2023-10-11 16:52     ` Bart Van Assche
2023-10-12  8:49       ` Kanchan Joshi
2023-10-12 14:03         ` Niklas Cassel
2023-10-12 17:42         ` Bart Van Assche
2023-10-05 19:40 ` [PATCH v2 02/15] blk-ioprio: Modify " Bart Van Assche
2023-10-06  6:36   ` Kanchan Joshi
2023-10-06 18:25     ` Bart Van Assche
2023-10-05 19:40 ` [PATCH v2 03/15] block: Support data lifetime in the I/O priority bitfield Bart Van Assche
2023-10-06  6:42   ` Kanchan Joshi
2023-10-06  8:19   ` Damien Le Moal
2023-10-06  9:53     ` Niklas Cassel
2023-10-06 18:07     ` Bart Van Assche
2023-10-11 20:51       ` Bart Van Assche
2023-10-12  1:02         ` Damien Le Moal [this message]
2023-10-12 18:00           ` Bart Van Assche
2023-10-13  1:08             ` Damien Le Moal
2023-10-13  9:33               ` Niklas Cassel
2023-10-13 21:20                 ` Bart Van Assche
2023-10-16  9:20                   ` Niklas Cassel
2023-10-16 16:36                     ` Bart Van Assche
2023-10-13 20:18               ` Bart Van Assche
2023-10-15 22:22                 ` Damien Le Moal
2023-10-16 16:31                   ` Bart Van Assche
2023-10-16  6:17     ` Christoph Hellwig
2023-10-16 16:32       ` Bart Van Assche
2023-10-05 19:40 ` [PATCH v2 04/15] fs: Restore write hint support Bart Van Assche
2023-10-10  5:42   ` Kanchan Joshi
2023-10-11 16:56     ` Bart Van Assche
2023-10-16  6:20   ` Christoph Hellwig
2023-10-05 19:40 ` [PATCH v2 05/15] fs/f2fs: Restore the whint_mode mount option Bart Van Assche
2023-10-05 19:40 ` [PATCH v2 06/15] scsi: core: Query the Block Limits Extension VPD page Bart Van Assche
2023-10-05 19:40 ` [PATCH v2 07/15] scsi_proto: Add structures and constants related to I/O groups and streams Bart Van Assche
2023-10-05 19:40 ` [PATCH v2 08/15] sd: Translate data lifetime information Bart Van Assche
2023-10-05 19:40 ` [PATCH v2 09/15] scsi_debug: Reduce code duplication Bart Van Assche
2023-10-05 19:40 ` [PATCH v2 10/15] scsi_debug: Support the block limits extension VPD page Bart Van Assche
2023-10-05 19:40 ` [PATCH v2 11/15] scsi_debug: Rework page code error handling Bart Van Assche
2023-10-05 19:40 ` [PATCH v2 12/15] scsi_debug: Rework subpage " Bart Van Assche
2023-10-05 19:40 ` [PATCH v2 13/15] scsi_debug: Implement the IO Advice Hints Grouping mode page Bart Van Assche
2023-10-05 19:41 ` [PATCH v2 14/15] scsi_debug: Implement GET STREAM STATUS Bart Van Assche
2023-10-05 19:41 ` [PATCH v2 15/15] scsi_debug: Maintain write statistics per group number Bart Van Assche

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=447f3095-66cb-417b-b48c-90005d37b5d3@kernel.org \
    --to=dlemoal@kernel.org \
    --cc=Avri.Altman@wdc.com \
    --cc=Niklas.Cassel@wdc.com \
    --cc=axboe@kernel.dk \
    --cc=bvanassche@acm.org \
    --cc=daejun7.park@samsung.com \
    --cc=hare@suse.de \
    --cc=hch@lst.de \
    --cc=huobean@gmail.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).