Linux block layer
 help / color / mirror / Atom feed
From: Bart Van Assche <bvanassche@acm.org>
To: 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>
Subject: Re: [PATCH v3 00/14] Pass data temperature information to SCSI disk devices
Date: Wed, 18 Oct 2023 12:34:21 -0700	[thread overview]
Message-ID: <e8b49fac-77ce-4b61-ac4d-e4ace58d8319@acm.org> (raw)
In-Reply-To: <3f3c2289-3185-4895-92cb-0692e3ca9ebc@kernel.dk>


On 10/18/23 12:09, Jens Axboe wrote:
> My main hesitation with this is that there's a big gap between what
> makes theoretical sense and practical sense. When we previously tried
> this, turns out devices retained the data temperature on media, as
> expected, but tossed it out when data was GC'ed. That made it more of a
> benchmarking case than anything else. How do we know that things are
> better now? In previous postings I've seen you point at some papers, but
> I'm mostly concerned with practical use cases and devices. Are there any
> results, at all, from that? Or is this a case of vendors asking for
> something to check some marketing boxes or have value add?

Hi Jens,

Multiple UFS vendors made it clear to me that this feature is essential 
for their UFS devices to perform well. I will reach out to some of these
vendors off-list and will ask them to share performance numbers.

A note: persistent stream support is a feature that was only added
recently in the latest SCSI SBC-5 draft. This SCSI specification change
allows SCSI device vendors to interpret the GROUP NUMBER field as a data
lifetime. UFS device vendors interpret the GROUP NUMBER field as a data
lifetime since a long time - long before this was allowed by the SCSI
standards. See also the "ContextID" feature in the UFS specification.
That feature is mentioned in every version of the UFS specification I
have access to. The oldest version of the UFS specification I have
access to is version 2.2, published in 2016.
(https://www.jedec.org/system/files/docs/JESD220C-2_2.pdf). This
document is available free of charge after an account has been created 
on the JEDEC website.

> I'm also really against growing struct bio just for this. Why is patch 2
> not just using the ioprio field at least?

Hmm ... shouldn't the bits in the ioprio field in struct bio have the
same meaning as in the ioprio fields used in interfaces between user
space and the kernel? Damien Le Moal asked me not to use any of the
ioprio bits passing data lifetime information from user space to the kernel.

Is it clear that the size of struct bio has not been changed because the
new bi_lifetime member fills a hole in struct bio?

Thanks,

Bart.



  reply	other threads:[~2023-10-18 19:34 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-17 20:47 [PATCH v3 00/14] Pass data temperature information to SCSI disk devices Bart Van Assche
2023-10-17 20:47 ` [PATCH v3 01/14] fs: Move enum rw_hint into a new header file Bart Van Assche
2023-10-30 11:11   ` Kanchan Joshi
2023-10-30 16:10     ` Bart Van Assche
2023-11-01  6:39       ` Daejun Park
2023-11-01 16:45         ` (2) " Bart Van Assche
2023-11-02  7:31           ` Daejun Park
2023-10-17 20:47 ` [PATCH v3 02/14] block: Restore data lifetime support in struct bio and struct request Bart Van Assche
2023-10-17 20:47 ` [PATCH v3 03/14] fs: Restore write hint support Bart Van Assche
2023-10-17 20:47 ` [PATCH v3 04/14] fs/f2fs: Restore data lifetime support Bart Van Assche
2023-10-17 20:47 ` [PATCH v3 05/14] scsi: core: Query the Block Limits Extension VPD page Bart Van Assche
2023-10-17 20:47 ` [PATCH v3 06/14] scsi_proto: Add structures and constants related to I/O groups and streams Bart Van Assche
2023-10-17 20:47 ` [PATCH v3 07/14] sd: Translate data lifetime information Bart Van Assche
2023-10-17 20:47 ` [PATCH v3 08/14] scsi_debug: Reduce code duplication Bart Van Assche
2023-10-17 20:47 ` [PATCH v3 09/14] scsi_debug: Support the block limits extension VPD page Bart Van Assche
2023-10-17 20:47 ` [PATCH v3 10/14] scsi_debug: Rework page code error handling Bart Van Assche
2023-10-17 20:47 ` [PATCH v3 11/14] scsi_debug: Rework subpage " Bart Van Assche
2023-10-17 20:47 ` [PATCH v3 12/14] scsi_debug: Implement the IO Advice Hints Grouping mode page Bart Van Assche
2023-10-17 20:47 ` [PATCH v3 13/14] scsi_debug: Implement GET STREAM STATUS Bart Van Assche
2023-10-17 20:47 ` [PATCH v3 14/14] scsi_debug: Maintain write statistics per group number Bart Van Assche
2023-10-18 19:09 ` [PATCH v3 00/14] Pass data temperature information to SCSI disk devices Jens Axboe
2023-10-18 19:34   ` Bart Van Assche [this message]
2023-10-19  0:33     ` Damien Le Moal
2023-10-19 16:48       ` Bart Van Assche
2023-10-19 22:40         ` Damien Le Moal
2023-10-19 23:00           ` Damien Le Moal
2023-10-20 20:45   ` 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=e8b49fac-77ce-4b61-ac4d-e4ace58d8319@acm.org \
    --to=bvanassche@acm.org \
    --cc=Avri.Altman@wdc.com \
    --cc=Niklas.Cassel@wdc.com \
    --cc=axboe@kernel.dk \
    --cc=daejun7.park@samsung.com \
    --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