From: Jens Axboe <axboe@kernel.dk>
To: Goldwyn Rodrigues <rgoldwyn@suse.de>,
adam.manzanares@wdc.com, viro@zeniv.linux.org.uk,
linux-fsdevel@vger.kernel.org, bcrl@kvack.org
Cc: tglx@linutronix.de, mingo@kernel.org, pombredanne@nexb.com,
kstewart@linuxfoundation.org, gregkh@linuxfoundation.org,
bigeasy@linutronix.de, jack@suse.cz, darrick.wong@oracle.com,
linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-aio@kvack.org, linux-api@vger.kernel.org,
hch@infradread.org, jmoyer@redhat.com
Subject: Re: [PATCH v6 2/5] fs: Convert kiocb rw_hint from enum to u16
Date: Tue, 22 May 2018 10:30:36 -0600 [thread overview]
Message-ID: <58087b03-a3c7-93fd-d1ad-de77181e8806@kernel.dk> (raw)
In-Reply-To: <084d253c-52ab-7b23-521c-28602c56153b@suse.de>
On 5/22/18 10:24 AM, Goldwyn Rodrigues wrote:
>
>
> On 05/22/2018 10:32 AM, Jens Axboe wrote:
>> On 5/22/18 9:07 AM, adam.manzanares@wdc.com wrote:
>>> From: Adam Manzanares <adam.manzanares@wdc.com>
>>>
>>> In order to avoid kiocb bloat for per command iopriority support, rw_hint
>>> is converted from enum to a u16. Added a guard around ki_hint assignment.
>>>
>>> Signed-off-by: Adam Manzanares <adam.manzanares@wdc.com>
>>> Reviewed-by: Christoph Hellwig <hch@lst.de>
>>> ---
>>> include/linux/fs.h | 13 +++++++++++--
>>> 1 file changed, 11 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/include/linux/fs.h b/include/linux/fs.h
>>> index 7f07977bdfd7..50de40dbbb85 100644
>>> --- a/include/linux/fs.h
>>> +++ b/include/linux/fs.h
>>> @@ -284,6 +284,8 @@ enum rw_hint {
>>> WRITE_LIFE_EXTREME = RWH_WRITE_LIFE_EXTREME,
>>> };
>>>
>>> +#define MAX_KI_HINT ((1 << 16) - 1) /* ki_hint type is u16 */
>>
>> Instead of having to do this and now rely on those now being synced,
>> how about something like the below.
>>
>> diff --git a/include/linux/fs.h b/include/linux/fs.h
>> index 760d8da1b6c7..070438d0b62d 100644
>> --- a/include/linux/fs.h
>> +++ b/include/linux/fs.h
>> @@ -299,7 +299,7 @@ struct kiocb {
>> void (*ki_complete)(struct kiocb *iocb, long ret, long ret2);
>> void *private;
>> int ki_flags;
>> - enum rw_hint ki_hint;
>> + u16 ki_hint;
>> } __randomize_layout;
>>
>> static inline bool is_sync_kiocb(struct kiocb *kiocb)
>> @@ -1927,12 +1927,22 @@ static inline enum rw_hint file_write_hint(struct file *file)
>>
>> static inline int iocb_flags(struct file *file);
>>
>> +static inline u16 ki_hint_validate(enum rw_hint hint)
>> +{
>> + typeof(((struct kiocb *)0)->ki_hint) max_hint = -1;
>
> This looks complex to me. Would force a reader to lookback at what
> datatype ki_hint is. I'd prefer to declare it as u16 max_hint = -1, or
> even the previous #define MAX_KI_HINT format is easier to read. Just a
> program reading style you are comfortable with though.
How is it complex? It's defining a type that'll be the same as ki_hint
in the kiocb, which is _exactly_ what we care about. Any sort of other
definition will rely on those two locations now being synced. The
above will never break.
So I strongly disagree. The above will _never_ require the reader to
figure out what the type is. Any other variant will _always_ require
the reader to check if they are the same.
--
Jens Axboe
next prev parent reply other threads:[~2018-05-22 16:30 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-22 15:07 [PATCH v6 0/5] AIO add per-command iopriority adam.manzanares
2018-05-22 15:07 ` [PATCH v6 1/5] block: add ioprio_check_cap function adam.manzanares
2018-05-22 15:07 ` [PATCH v6 2/5] fs: Convert kiocb rw_hint from enum to u16 adam.manzanares
2018-05-22 15:32 ` Jens Axboe
2018-05-22 15:43 ` Adam Manzanares
2018-05-22 16:24 ` Goldwyn Rodrigues
2018-05-22 16:30 ` Jens Axboe [this message]
2018-05-22 17:22 ` Adam Manzanares
2018-05-22 15:07 ` [PATCH v6 3/5] fs: Add aio iopriority support adam.manzanares
2018-05-22 15:07 ` [PATCH v6 4/5] fs: blkdev set bio prio from kiocb prio adam.manzanares
2018-05-22 15:15 ` Jeff Moyer
2018-05-22 15:07 ` [PATCH v6 5/5] fs: iomap dio " adam.manzanares
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=58087b03-a3c7-93fd-d1ad-de77181e8806@kernel.dk \
--to=axboe@kernel.dk \
--cc=adam.manzanares@wdc.com \
--cc=bcrl@kvack.org \
--cc=bigeasy@linutronix.de \
--cc=darrick.wong@oracle.com \
--cc=gregkh@linuxfoundation.org \
--cc=hch@infradread.org \
--cc=jack@suse.cz \
--cc=jmoyer@redhat.com \
--cc=kstewart@linuxfoundation.org \
--cc=linux-aio@kvack.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=pombredanne@nexb.com \
--cc=rgoldwyn@suse.de \
--cc=tglx@linutronix.de \
--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).