Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Andreas Dilger <adilger@dilger.ca>
Message-Id: <9BD0C782-5967-4DCB-9D01-E5BCC73E653C@dilger.ca>
Content-Type: multipart/signed;
 boundary="Apple-Mail=_E3FEA83A-9256-40CD-B4F8-E3FF6FED0F48";
 protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: [PATCH v4 4/7] block: introduce write-hint to stream-id
 conversion
Date:   Thu, 18 Apr 2019 12:58:14 -0600
In-Reply-To: <20190418140603.GL28541@quack2.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
To:     Jan Kara <jack@suse.cz>
References: <1555523406-2380-1-git-send-email-joshi.k@samsung.com>
 <CGME20190417175358epcas1p41a0a4e349dfe0a70bdcc244161c71604@epcas1p4.samsung.com>
 <1555523406-2380-5-git-send-email-joshi.k@samsung.com>
 <20190418140603.GL28541@quack2.suse.cz>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


--Apple-Mail=_E3FEA83A-9256-40CD-B4F8-E3FF6FED0F48
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Apr 18, 2019, at 8:06 AM, Jan Kara <jack@suse.cz> wrote:
>=20
> 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 =3D 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.
>>=20
>> Signed-off-by: Kanchan Joshi <joshi.k@samsung.com>
>> ---
>> block/blk-core.c       | 20 ++++++++++++++++++++
>> include/linux/blkdev.h |  1 +
>> 2 files changed, 21 insertions(+)
>>=20
>> 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;
>> }
>>=20
>> +enum rw_hint blk_write_hint_to_streamid(struct request *req,
>> +				        struct bio *bio)
>> +{
>> +	enum rw_hint streamid, nr_streams;
>> +	struct request_queue *q =3D req->q;
>> +	nr_streams =3D q->limits.nr_streams;
>> +
>> +	streamid =3D bio->bi_write_hint;
>> +	if (!nr_streams || streamid =3D=3D WRITE_LIFE_NOT_SET ||
>> +	    streamid =3D=3D WRITE_LIFE_NONE)
>> +		streamid =3D 0;
>> +	else {
>> +		--streamid;
>> +		if(streamid > nr_streams)
>> +			streamid =3D 0;
>> +	}
>> +	return streamid;
>> +}
>> +
>=20
> 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:
>=20
> 	if (streamid <=3D BLK_MAX_USER_HINTS) {
> 		streamid--;
> 		if (streamid > nr_streams)
> 			streamid =3D 0;
> 	} else {
> 		/* Kernel hints get allocated from top */
> 		streamid -=3D WRITE_LIFE_KERN_MIN;
> 		if (streamid > nr_streams - BLK_MAX_USER_HINTS)
> 			streamid =3D 0;
> 		else
> 			streamid =3D nr_streams - streamid - 1;
> 	}
>=20
> 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


--Apple-Mail=_E3FEA83A-9256-40CD-B4F8-E3FF6FED0F48
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIzBAEBCAAdFiEEDb73u6ZejP5ZMprvcqXauRfMH+AFAly4yMcACgkQcqXauRfM
H+D0PRAAqc1IZBlPSc3z+RpgV6C85m4l3Yd3cAYdG+R0kOOUx23t/z/vT9Sb0Qgr
mohRguY/t1dzZ9Kmu/XPYpuMVX2VNnymVjldxVVea7V0NYuEb7qDzMvPKrGr1tIR
rHh4vrrx+Riq+4K6TqjfgsJI6hdjIhCTU37VcCcAW9/3tHOTHPpYuhcvSpIzAGxc
60Zm+btRFcrx0wKRd/F0x9D1tbv0LKXJlaC3bD6OquZ0QbM8Z4TncHkl4NjwG7IN
iNJOOoYJKm623G3aJMLyPlXnJ5KCTgr9Swy4fiJDQOqtFb1oU0Jd2/1+gIXSmIVD
sZ+72FId74kf5Iu3Upr9tFtRdFs/IkUVVJVKDOmpeTO0FJXVkIgejpKwhJTzhWE8
E50OkTAgEg11+6VfI072rhudkK5FbXZ3ACVnJp+htOdLiT6etlyYEfpE35l+mUhE
XJ2TavOJi9P+SQ3VSsSpEXzNBDfho838ZkwaH43LdmBIWeZCdymf2FHS3DJ9mDOi
ihGr0DQGQAqLwbgD+zjNI9dCXoTiGp4+SDA0CcfwNPc6j8CPtFpguCmrQu/FJTRF
GjXBTeu07u+kw0Nh0B3nDbieS87ObR8XOqGtvQHCC0sOkIfr78KnKahgICXsqAna
Mo9d9G6Iq6nW/oY4fgk2ZVFgL+ubMJX0h2ho4I9MxtdonFabeTk=
=vct3
-----END PGP SIGNATURE-----

--Apple-Mail=_E3FEA83A-9256-40CD-B4F8-E3FF6FED0F48--