From: Christoph Hellwig <hch@lst.de>
To: Kanchan Joshi <joshi.k@samsung.com>
Cc: Christoph Hellwig <hch@lst.de>,
Bart Van Assche <bvanassche@acm.org>,
"Martin K . Petersen" <martin.petersen@oracle.com>,
linux-scsi@vger.kernel.org, linux-block@vger.kernel.org,
linux-fsdevel@vger.kernel.org, Jens Axboe <axboe@kernel.dk>,
Daejun Park <daejun7.park@samsung.com>, Jan Kara <jack@suse.cz>,
Christian Brauner <brauner@kernel.org>,
Jaegeuk Kim <jaegeuk@kernel.org>, Chao Yu <chao@kernel.org>,
Alexander Viro <viro@zeniv.linux.org.uk>
Subject: Re: [PATCH v4 01/15] fs: Rename the kernel-internal data lifetime constants
Date: Mon, 27 Nov 2023 10:29:33 +0100 [thread overview]
Message-ID: <20231127092933.GA3572@lst.de> (raw)
In-Reply-To: <1e2481ac-6075-c940-327b-350f1d4b9ee5@samsung.com>
On Mon, Nov 27, 2023 at 02:15:51PM +0530, Kanchan Joshi wrote:
> How about this argument (assuming you may not have seen) from previous
> iteration [1]-
>
> "Does it make sense to do away with these, and have temperature-neutral
> names instead e.g., WRITE_LIFE_1, WRITE_LIFE_2?
>
> With the current choice:
> - If the count goes up (beyond 5 hints), infra can scale fine but these
> names do not. Imagine ULTRA_EXTREME after EXTREME.
> - Applications or in-kernel users can specify LONG hint with data that
> actually has a SHORT lifetime. Nothing really ensures that LONG is
> really LONG.
>
> Temperature-neutral names seem more generic/scalable and do not present
> the unnecessary need to be accurate with relative temperatures."
I don't really buy it, as that's not the use case we currently have,
which hasn't changed. And even if we did, life would probably be
simpler if you decoupled it from this series..
But IFF we decided to do away with the meanings, having constants
that just are numbered simply doesn't make any sense.
next prev parent reply other threads:[~2023-11-27 9:29 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-14 21:40 [PATCH v4 00/15] Pass data lifetime information to SCSI disk devices Bart Van Assche
2023-11-14 21:40 ` [PATCH v4 01/15] fs: Rename the kernel-internal data lifetime constants Bart Van Assche
2023-11-20 7:19 ` Kanchan Joshi
2023-11-27 7:08 ` Christoph Hellwig
2023-11-27 8:45 ` Kanchan Joshi
2023-11-27 9:29 ` Christoph Hellwig [this message]
2023-11-27 19:00 ` Bart Van Assche
2023-11-14 21:40 ` [PATCH v4 02/15] fs: Move enum rw_hint into a new header file Bart Van Assche
2023-11-14 21:40 ` [PATCH v4 03/15] block: Restore data lifetime support in struct bio and struct request Bart Van Assche
2023-11-14 21:40 ` [PATCH v4 04/15] fs: Restore write hint support Bart Van Assche
2023-11-14 21:41 ` [PATCH v4 05/15] fs/f2fs: Restore data lifetime support Bart Van Assche
2023-11-20 7:36 ` Kanchan Joshi
2023-11-20 17:53 ` Bart Van Assche
2023-11-14 21:41 ` [PATCH v4 06/15] scsi: core: Query the Block Limits Extension VPD page Bart Van Assche
2023-11-14 21:41 ` [PATCH v4 07/15] scsi_proto: Add structures and constants related to I/O groups and streams Bart Van Assche
2023-11-14 21:41 ` [PATCH v4 08/15] sd: Translate data lifetime information Bart Van Assche
2023-11-14 21:41 ` [PATCH v4 09/15] scsi_debug: Reduce code duplication Bart Van Assche
2023-11-14 21:41 ` [PATCH v4 10/15] scsi_debug: Support the block limits extension VPD page Bart Van Assche
2023-11-14 21:41 ` [PATCH v4 11/15] scsi_debug: Rework page code error handling Bart Van Assche
2023-11-14 21:41 ` [PATCH v4 12/15] scsi_debug: Rework subpage " Bart Van Assche
2023-11-14 21:41 ` [PATCH v4 13/15] scsi_debug: Implement the IO Advice Hints Grouping mode page Bart Van Assche
2023-11-14 21:41 ` [PATCH v4 14/15] scsi_debug: Implement GET STREAM STATUS Bart Van Assche
2023-11-14 21:41 ` [PATCH v4 15/15] scsi_debug: Maintain write statistics per group number Bart Van Assche
2023-11-21 19:25 ` 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=20231127092933.GA3572@lst.de \
--to=hch@lst.de \
--cc=axboe@kernel.dk \
--cc=brauner@kernel.org \
--cc=bvanassche@acm.org \
--cc=chao@kernel.org \
--cc=daejun7.park@samsung.com \
--cc=jack@suse.cz \
--cc=jaegeuk@kernel.org \
--cc=joshi.k@samsung.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=viro@zeniv.linux.org.uk \
/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).