linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Kanchan Joshi <joshi.k@samsung.com>
Cc: Christoph Hellwig <hch@lst.de>,
	axboe@kernel.dk, kbusch@kernel.org, sagi@grimberg.me,
	martin.petersen@oracle.com,
	James.Bottomley@HansenPartnership.com, brauner@kernel.org,
	viro@zeniv.linux.org.uk, jack@suse.cz, jaegeuk@kernel.org,
	jlayton@kernel.org, chuck.lever@oracle.com, bvanassche@acm.org,
	linux-nvme@lists.infradead.org, linux-fsdevel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net,
	linux-block@vger.kernel.org, linux-scsi@vger.kernel.org,
	gost.dev@samsung.com, vishak.g@samsung.com,
	javier.gonz@samsung.com, Nitesh Shetty <nj.shetty@samsung.com>
Subject: Re: [PATCH v5 4/5] sd: limit to use write life hints
Date: Tue, 17 Sep 2024 08:20:07 +0200	[thread overview]
Message-ID: <20240917062007.GA4170@lst.de> (raw)
In-Reply-To: <4a39215a-1b0e-3832-93bd-61e422705f8b@samsung.com>

On Mon, Sep 16, 2024 at 07:19:21PM +0530, Kanchan Joshi wrote:
> > Maybe part of the problem is that the API is very confusing.  A smal
> > part of that is of course that the existing temperature hints already
> > have some issues, but this seems to be taking them make it significantly
> > worse.
> 
> Can you explain what part is confusing. This is a simple API that takes 
> type/value pair. Two types (and respective values) are clearly defined 
> currently, and more can be added in future.

I though I outlined that below.

> > But if we increase this to a variable number of hints that don't have
> > any meaning (and even if that is just the rough order of the temperature
> > hints assigned to them), that doesn't really work.  We'll need an API
> > to check if these stream hints are supported and how many of them,
> > otherwise the applications can't make any sensible use of them.
> 
> - Since writes are backward compatible, nothing bad happens if the 
> passed placement-hint value is not supported. Maybe desired outcome (in 
> terms of WAF reduction) may not come but that's not a kernel problem 
> anyway. It's rather about how well application is segregating and how 
> well device is doing its job.

What do you mean with "writes are backward compatible" ?

> - Device is perfectly happy to work with numbers (0 to 256 in current 
> spec) to produce some value (i.e., WAF reduction). Any extra 
> semantics/abstraction on these numbers only adds to the work without 
> increasing that value. If any application needs that, it's free to 
> attach any meaning/semantics to these numbers.

If the device (or file system, which really needs to be in control
for actual files vs just block devices) does not support all 256
we need to reduce them to less than that.  The kernel can help with
that a bit if the streams have meanings (collapsing temperature levels
that are close), but not at all if they don't have meanings.  The
application can and thus needs to know the number of separate
streams available.


  reply	other threads:[~2024-09-17  6:20 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20240910151040epcas5p3f47fa7ea37a35f8b44dd9174689e1bb9@epcas5p3.samsung.com>
2024-09-10 15:01 ` [PATCH v5 0/5] data placement hints and FDP Kanchan Joshi
     [not found]   ` <CGME20240910151044epcas5p37f61bb85ccf8b3eb875e77c3fc260c51@epcas5p3.samsung.com>
2024-09-10 15:01     ` [PATCH v5 1/5] fs, block: refactor enum rw_hint Kanchan Joshi
2024-09-12 12:53       ` Christoph Hellwig
2024-09-12 15:50         ` Kanchan Joshi
2024-09-12 20:30           ` Bart Van Assche
2024-09-13  7:22             ` Kanchan Joshi
     [not found]   ` <CGME20240910151048epcas5p3c610d63022362ec5fcc6fc362ad2fb9f@epcas5p3.samsung.com>
2024-09-10 15:01     ` [PATCH v5 2/5] fcntl: rename rw_hint_* to rw_lifetime_hint_* Kanchan Joshi
2024-09-12 12:54       ` Christoph Hellwig
2024-09-12 15:51         ` Kanchan Joshi
     [not found]   ` <CGME20240910151052epcas5p48b20962753b1e3171daf98f050d0b5af@epcas5p4.samsung.com>
2024-09-10 15:01     ` [PATCH v5 3/5] fcntl: add F_{SET/GET}_RW_HINT_EX Kanchan Joshi
2024-09-10 18:48       ` Jens Axboe
2024-09-11 15:50         ` Kanchan Joshi
2024-09-12 13:01       ` Christoph Hellwig
2024-09-12 15:53         ` Kanchan Joshi
2024-09-12 20:36       ` Bart Van Assche
2024-09-13  7:15         ` Kanchan Joshi
     [not found]   ` <CGME20240910151057epcas5p3369c6257a6f169b4caa6dd59548b538c@epcas5p3.samsung.com>
2024-09-10 15:01     ` [PATCH v5 4/5] sd: limit to use write life hints Kanchan Joshi
2024-09-12 13:02       ` Christoph Hellwig
2024-09-12 16:31         ` Kanchan Joshi
2024-09-13  8:06           ` Christoph Hellwig
2024-09-16 13:49             ` Kanchan Joshi
2024-09-17  6:20               ` Christoph Hellwig [this message]
2024-09-17 16:03                 ` Kanchan Joshi
2024-09-17 17:00                   ` Kanchan Joshi
2024-09-18  6:42                   ` Christoph Hellwig
2024-09-18  8:12                     ` Kanchan Joshi
2024-09-18 12:01                       ` Christoph Hellwig
2024-09-24  9:24                         ` Kanchan Joshi
2024-09-24  9:28                           ` Christoph Hellwig
     [not found]   ` <CGME20240910151101epcas5p1c4e90f7334125fc49106d58d43cffcec@epcas5p1.samsung.com>
2024-09-10 15:02     ` [PATCH v5 5/5] nvme: enable FDP support Kanchan Joshi
2025-01-29  0:56   ` [f2fs-dev] [PATCH v5 0/5] data placement hints and FDP patchwork-bot+f2fs

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=20240917062007.GA4170@lst.de \
    --to=hch@lst.de \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=axboe@kernel.dk \
    --cc=brauner@kernel.org \
    --cc=bvanassche@acm.org \
    --cc=chuck.lever@oracle.com \
    --cc=gost.dev@samsung.com \
    --cc=jack@suse.cz \
    --cc=jaegeuk@kernel.org \
    --cc=javier.gonz@samsung.com \
    --cc=jlayton@kernel.org \
    --cc=joshi.k@samsung.com \
    --cc=kbusch@kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=nj.shetty@samsung.com \
    --cc=sagi@grimberg.me \
    --cc=viro@zeniv.linux.org.uk \
    --cc=vishak.g@samsung.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).