> Il giorno 25 gen 2017, alle ore 17:13, Jens Axboe <axboe@xxxxxx> ha scritto: > > On 01/25/2017 01:46 AM, Paolo Valente wrote: >> >>> Il giorno 23 gen 2017, alle ore 18:42, Jens Axboe <axboe@xxxxxx> ha scritto: >>> >>> On 01/23/2017 10:04 AM, Paolo Valente wrote: >>>> >>>>> Il giorno 18 gen 2017, alle ore 17:21, Jens Axboe <axboe@xxxxxx> ha scritto: >>>>> >>>>> On 01/18/2017 08:14 AM, Paolo Valente wrote: >>>>>> according to the function blk_mq_sched_put_request, the >>>>>> mq.completed_request hook seems to always be invoked (if set) for a >>>>>> request for which the mq.put_rq_priv is invoked (if set). >>>>> >>>>> Correct, any request that came out of blk_mq_sched_get_request() >>>>> will always have completed called on it, regardless of whether it >>>>> had IO started on it or not. >>>>> >>>> >>>> It seems that some request, after being dispatched, happens to have no >>>> mq.put_rq_priv invoked on it now or then. Is it expected? If it is, >>>> could you point me to the path through which the end of the life of >>>> such a request is handled? >>> >>> I'm guessing that's a flush request. I added RQF_QUEUED to check for >>> that, if RQF_QUEUED is set, you know it has come from your get_request >>> handler. >>> >> >> Exactly, the completion-without-put_rq_priv pattern seems to occur >> only for requests coming from the flusher, precisely because they have >> the flag RQF_ELVPRIV unset. Just to understand: why is this flag >> unset for these requests, if they do have private elevator (bfq) >> data attached? What am I misunderstanding? >> >> Just to be certain: this should be the only case where the >> completed_request hook is invoked while the put_rq_priv is not, right? > > They must NOT have scheduler data attached. In your get_request > function, you must bypass if blk_mq_sched_bypass_insert() returns true. Yes, sorry. I'm already using blk_mq_sched_bypass_insert() to bypass insertion in the insert hook, as done in mq-deadline, and I have no get_request defined (see below). The source of my confusion was that I assumed that flush requests had not to leave any trace in the scheduler, since the scheduler does not decide anything for them. Accordingly, I thought they did not trigger any put or completion hook. In contrast, these requests get the flag QUEUED set, in case the get_request hook is set, and then trigger both a put_request and a completed_request. In this respect, in bfq-mq I'm not using any of these three hooks (they are all NULL). I hope I'm not doing something unexpected or incoherent. UPDATE: bfq-mq now survives for minutes. I'm debugging two occasional failures, which (un)fortunately become more and more occasional as I go on with debugging and instrumenting the code. Thanks, Paolo > See how mq-deadline does that. This is important, or you will get hangs > with flushes as well, since the IO scheduler private data and the flush > data is unionized in the request. > > -- > Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
