[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c2055f86-08f8-582f-7055-23f272f057c4@wdc.com>
Date: Fri, 18 May 2018 15:29:21 +0000
From: Adam Manzanares <Adam.Manzanares@....com>
To: Jens Axboe <axboe@...nel.dk>,
"viro@...iv.linux.org.uk" <viro@...iv.linux.org.uk>,
"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
"bcrl@...ck.org" <bcrl@...ck.org>
CC: "mingo@...nel.org" <mingo@...nel.org>,
"peterz@...radead.org" <peterz@...radead.org>,
"pombredanne@...b.com" <pombredanne@...b.com>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
"bigeasy@...utronix.de" <bigeasy@...utronix.de>,
"rgoldwyn@...e.com" <rgoldwyn@...e.com>,
"linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-aio@...ck.org" <linux-aio@...ck.org>,
"linux-api@...r.kernel.org" <linux-api@...r.kernel.org>
Subject: Re: [PATCH v4 3/3] fs: Add aio iopriority support for block_dev
On 5/18/18 8:14 AM, Jens Axboe wrote:
> On 5/17/18 2:38 PM, adam.manzanares@....com wrote:
>> From: Adam Manzanares <adam.manzanares@....com>
>>
>> This is the per-I/O equivalent of the ioprio_set system call.
>>
>> When IOCB_FLAG_IOPRIO is set on the iocb aio_flags field, then we set the
>> newly added kiocb ki_ioprio field to the value in the iocb aio_reqprio field.
>>
>> When a bio is created for an aio request by the block dev we set the priority
>> value of the bio to the user supplied value.
>>
>> This patch depends on block: add ioprio_check_cap function
>
> Actually, one comment on this one:
>
>> diff --git a/fs/aio.c b/fs/aio.c
>> index f3eae5d5771b..ff3107aa82d5 100644
>> --- a/fs/aio.c
>> +++ b/fs/aio.c
>> @@ -1451,6 +1451,22 @@ static int aio_prep_rw(struct kiocb *req, struct iocb *iocb)
>> if (iocb->aio_flags & IOCB_FLAG_RESFD)
>> req->ki_flags |= IOCB_EVENTFD;
>> req->ki_hint = file_write_hint(req->ki_filp);
>> + if (iocb->aio_flags & IOCB_FLAG_IOPRIO) {
>> + /*
>> + * If the IOCB_FLAG_IOPRIO flag of aio_flags is set, then
>> + * aio_reqprio is interpreted as an I/O scheduling
>> + * class and priority.
>> + */
>> + ret = ioprio_check_cap(iocb->aio_reqprio);
>> + if (ret) {
>> + pr_debug("aio ioprio check cap error\n");
>> + return -EINVAL;
>> + }
>> +
>> + req->ki_ioprio = iocb->aio_reqprio;
>> + req->ki_flags |= IOCB_IOPRIO;
>> + }
>
> Do we really need IOCB_IOPRIO? All zeroes is no priority set anyway,
> so we should be able to get by with just setting ->ki_ioprio to either
> the priority, or 0.
>
>> diff --git a/fs/block_dev.c b/fs/block_dev.c
>> index 7ec920e27065..970bef79caa6 100644
>> --- a/fs/block_dev.c
>> +++ b/fs/block_dev.c
>> @@ -355,6 +355,8 @@ __blkdev_direct_IO(struct kiocb *iocb, struct iov_iter *iter, int nr_pages)
>> bio->bi_write_hint = iocb->ki_hint;
>> bio->bi_private = dio;
>> bio->bi_end_io = blkdev_bio_end_io;
>> + if (iocb->ki_flags & IOCB_IOPRIO)
>> + bio->bi_ioprio = iocb->ki_ioprio;
>
> And then this assignment can just happen unconditionally.
That is a cleaner way of guaranteeing the ioprio set on the kiocb is
only set when the user intends to use the ioprio from the iocb.
I'll resend the series.
>
Powered by blists - more mailing lists