From: Andreas Dilger <adilger@dilger.ca>
To: Jan Kara <jack@suse.cz>
Cc: Kanchan Joshi <joshi.k@samsung.com>,
open list <linux-kernel@vger.kernel.org>,
linux-block <linux-block@vger.kernel.org>,
linux-nvme@lists.infradead.org,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
linux-ext4@vger.kernel.org, prakash.v@samsung.com
Subject: Re: [PATCH v4 4/7] block: introduce write-hint to stream-id conversion
Date: Thu, 18 Apr 2019 12:58:14 -0600 [thread overview]
Message-ID: <9BD0C782-5967-4DCB-9D01-E5BCC73E653C@dilger.ca> (raw)
In-Reply-To: <20190418140603.GL28541@quack2.suse.cz>
[-- Attachment #1: Type: text/plain, Size: 2774 bytes --]
On Apr 18, 2019, at 8:06 AM, Jan Kara <jack@suse.cz> wrote:
>
> On Wed 17-04-19 23:20:03, Kanchan Joshi wrote:
>> This patch moves write-hint-to-stream-id conversion in block-layer.
>> Earlier this was done by driver (nvme). Current conversion is of the
>> form "streamid = write-hint - 1", for both user and kernel streams.
>> Conversion takes stream limit (maintained in request queue) into
>> account. Write-hints beyond the exposed limit turn to 0.
>> A new field 'streamid' has been added in request. While 'write-hint'
>> field continues to exist. It keeps original value passed from upper
>> layer, and used during merging checks.
>>
>> Signed-off-by: Kanchan Joshi <joshi.k@samsung.com>
>> ---
>> block/blk-core.c | 20 ++++++++++++++++++++
>> include/linux/blkdev.h | 1 +
>> 2 files changed, 21 insertions(+)
>>
>> diff --git a/block/blk-core.c b/block/blk-core.c
>> index a55389b..712e6b7 100644
>> --- a/block/blk-core.c
>> +++ b/block/blk-core.c
>> @@ -730,6 +730,25 @@ bool blk_attempt_plug_merge(struct request_queue *q, struct bio *bio,
>> return false;
>> }
>>
>> +enum rw_hint blk_write_hint_to_streamid(struct request *req,
>> + struct bio *bio)
>> +{
>> + enum rw_hint streamid, nr_streams;
>> + struct request_queue *q = req->q;
>> + nr_streams = q->limits.nr_streams;
>> +
>> + streamid = bio->bi_write_hint;
>> + if (!nr_streams || streamid == WRITE_LIFE_NOT_SET ||
>> + streamid == WRITE_LIFE_NONE)
>> + streamid = 0;
>> + else {
>> + --streamid;
>> + if(streamid > nr_streams)
>> + streamid = 0;
>> + }
>> + return streamid;
>> +}
>> +
>
> Someone told me that stream ids are potentially persistent on the storage
> so it isn't great to change the id for the same thing e.g. if we add
> another user hint. So maybe we should allocate kernel hints from top as
> Dave Chinner suggested? I.e., something like the following mapping function:
>
> if (streamid <= BLK_MAX_USER_HINTS) {
> streamid--;
> if (streamid > nr_streams)
> streamid = 0;
> } else {
> /* Kernel hints get allocated from top */
> streamid -= WRITE_LIFE_KERN_MIN;
> if (streamid > nr_streams - BLK_MAX_USER_HINTS)
> streamid = 0;
> else
> streamid = nr_streams - streamid - 1;
> }
>
> what do you think?
Dave has expressed this sentiment several times, and I agree. We don't
want the filesystem hint values/mapping to change over time, or it will
conflict with data that was written with the previous hints (e.g. if
data was written with a "short lifetime" hint suddenly changes to be
grouped with a "long lifetime" hint). This is easily avoided with some
simple changes now, but harder to fix after this patch has landed.
Cheers, Andreas
[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 873 bytes --]
next prev parent reply other threads:[~2019-04-18 18:58 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20190417175347epcas2p41e4240ab83b46c9f07d237fc9494903a@epcas2p4.samsung.com>
2019-04-17 17:49 ` [PATCH v4 0/7] Extend write-hint/stream infrastructure Kanchan Joshi
[not found] ` <CGME20190417175351epcas1p481ec1bd87188022020a504447e88fde4@epcas1p4.samsung.com>
2019-04-17 17:50 ` [PATCH v4 1/7] fs: introduce write-hint start point for in-kernel hints Kanchan Joshi
[not found] ` <CGME20190417175353epcas2p1eaec3fea0bf26bb97416149e11b1317e@epcas2p1.samsung.com>
2019-04-17 17:50 ` [PATCH v4 2/7] block: increase stream count for in-kernel use Kanchan Joshi
[not found] ` <CGME20190417175355epcas2p182a8626924a911310f7584d564d0a1ec@epcas2p1.samsung.com>
2019-04-17 17:50 ` [PATCH v4 3/7] block: introduce API to register stream information with block-layer Kanchan Joshi
[not found] ` <CGME20190417175358epcas1p41a0a4e349dfe0a70bdcc244161c71604@epcas1p4.samsung.com>
2019-04-17 17:50 ` [PATCH v4 4/7] block: introduce write-hint to stream-id conversion Kanchan Joshi
2019-04-17 17:57 ` Jens Axboe
2019-04-22 13:36 ` kanchan
2019-04-18 14:06 ` Jan Kara
2019-04-18 18:58 ` Andreas Dilger [this message]
2019-04-22 13:33 ` kanchan
[not found] ` <CGME20190417175400epcas2p2b166bfaef69f5a02e856743be76199f3@epcas2p2.samsung.com>
2019-04-17 17:50 ` [PATCH v4 5/7] nvme: register stream info with block layer Kanchan Joshi
2019-04-18 13:52 ` Jan Kara
2019-04-22 13:43 ` kanchan
[not found] ` <CGME20190417175402epcas1p450f2617234aadf24cb4c8ae184d48c68@epcas1p4.samsung.com>
2019-04-17 17:50 ` [PATCH v4 6/7] fs: introduce APIs to enable passing write-hint with buffer-head Kanchan Joshi
[not found] ` <CGME20190417175404epcas2p1380bc5b15bd1e3c09866765c581a34c3@epcas2p1.samsung.com>
2019-04-17 17:50 ` [PATCH v4 7/7] fs/ext4,jbd2: add support for sending write-hint with journal Kanchan Joshi
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=9BD0C782-5967-4DCB-9D01-E5BCC73E653C@dilger.ca \
--to=adilger@dilger.ca \
--cc=jack@suse.cz \
--cc=joshi.k@samsung.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=prakash.v@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).