On Thu, Oct 13, 2016 at 1:09 PM, Jens Axboe <axboe@xxxxxxxxx> wrote: > On 10/13/2016 02:06 PM, Dan Williams wrote: >> >> On Thu, Oct 13, 2016 at 12:53 PM, Adam Manzanares >> <adam.manzanares@xxxxxxxx> wrote: >>> >>> Patch adds an association between iocontext ioprio and the ioprio of a >>> request. This value is set in blk_rq_set_prio which takes the request and >>> the ioc as arguments. If the ioc is valid in blk_rq_set_prio then the >>> iopriority of the request is set as the iopriority of the ioc. In >>> init_request_from_bio a check is made to see if the ioprio of the bio is >>> valid and if so then the request prio comes from the bio. >>> >>> Signed-off-by: Adam Manzananares <adam.manzanares@xxxxxxx> >>> --- >>> block/blk-core.c | 4 +++- >>> include/linux/blkdev.h | 14 ++++++++++++++ >>> 2 files changed, 17 insertions(+), 1 deletion(-) >>> >>> diff --git a/block/blk-core.c b/block/blk-core.c >>> index 14d7c07..361b1b9 100644 >>> --- a/block/blk-core.c >>> +++ b/block/blk-core.c >>> @@ -1153,6 +1153,7 @@ static struct request *__get_request(struct >>> request_list *rl, int op, >>> >>> blk_rq_init(q, rq); >>> blk_rq_set_rl(rq, rl); >>> + blk_rq_set_prio(rq, ioc); >>> req_set_op_attrs(rq, op, op_flags | REQ_ALLOCED); >>> >>> /* init elvpriv */ >>> @@ -1656,7 +1657,8 @@ void init_request_from_bio(struct request *req, >>> struct bio *bio) >>> >>> req->errors = 0; >>> req->__sector = bio->bi_iter.bi_sector; >>> - req->ioprio = bio_prio(bio); >>> + if (ioprio_valid(bio_prio(bio))) >>> + req->ioprio = bio_prio(bio); >> >> >> Should we use ioprio_best() here? If req->ioprio and bio_prio() >> disagree one side has explicitly asked for a higher priority. > > > It's a good question - but if priority has been set in the bio, it makes > sense that that would take priority over the general setting for the > task/io context. So I think the patch is correct as-is. Assuming you always trust the kernel to know the right priority... -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
