[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <a22de016-686f-ce93-c311-71a6719ee521@wdc.com>
Date: Wed, 9 May 2018 15:29:00 +0000
From: Adam Manzanares <Adam.Manzanares@....com>
To: Jens Axboe <axboe@...nel.dk>,
"viro@...iv.linux.org.uk" <viro@...iv.linux.org.uk>,
"bcrl@...ck.org" <bcrl@...ck.org>,
"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
"linux-aio@...ck.org" <linux-aio@...ck.org>,
"linux-api@...r.kernel.org" <linux-api@...r.kernel.org>,
"linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 2/3] fs: Convert kiocb rw_hint from enum to u16
On 5/9/18 11:21 AM, Theodore Y. Ts'o wrote:
> On Wed, May 09, 2018 at 08:23:00AM -0600, Jens Axboe wrote:
>> Streams is essentially the only thing ki_hint is currently used for,
>> with the write life time hints mapping to a stream. The idea for the
>> user side API was to have other things than just write life time hints.
>>
>> Since Adam wants to do priorities, he'd either need to pack into the
>> existing ki_hint, or do this patch does, which is make it smaller and
>> add a new member. I think the latter is cleaner.
>
> Fair enough; but maybe we can use a u8 instead of a u16? 65,535
> priorities still seem like way more than would ever make sense. I
> think 256 priorities is still way to many, but it's simpler while
> still reserving number of bits for future se.
The intention was to mimic the ioprio_set system call, which uses 3 bits
for a prio class and 13 bits for a prio_value.
IDK what is the right amount of bits to use, but the existing use of
bits seemed flexible enough to support many types of applications and
devices.
>
> - Ted
>
Powered by blists - more mailing lists