[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190402092044.GE12133@quack2.suse.cz>
Date: Tue, 2 Apr 2019 11:20:44 +0200
From: Jan Kara <jack@...e.cz>
To: Dave Chinner <david@...morbit.com>
Cc: Kanchan Joshi <joshi.k@...sung.com>, linux-kernel@...r.kernel.org,
linux-block@...r.kernel.org, linux-nvme@...ts.infradead.org,
linux-fsdevel@...r.kernel.org, linux-ext4@...r.kernel.org,
axboe@...com, prakash.v@...sung.com, anshul@...sung.com,
joshiiitr@...il.com
Subject: Re: [PATCH v3 3/7] block: add write-hint to stream-id conversion
On Mon 01-04-19 16:08:21, Dave Chinner wrote:
> On Fri, Mar 29, 2019 at 01:23:48PM +0530, Kanchan Joshi wrote:
> > + if(streamid > nr_streams)
> > + streamid = 0;
>
> So, basically, we'll compress all the kernel hints down to "no hint"
> if there are more user streams than the device supports?
>
> Surely we should be reserving a stream for the kernel hints separate
> from the user and "none" streams when we have limited device streams
> available...
The question is what to do in a situation when the device has exactly as
many hints as we currently offer to userspace. Because currently either the
device has enough hints for all userspace hint values or we disable the
feature altogether. If we always mandated some hints are available for the
kernel, we'd have to regress some fuctionality currently available to
userspace. So I think that the option that the kernel won't get any hints
is the least painful solution. Later when people would like to extend hints
available to userspace, we could make sure kernel's batch of hints has
priority over these "extended userspace hints".
Honza
--
Jan Kara <jack@...e.com>
SUSE Labs, CR
Powered by blists - more mailing lists