Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1563638
| From | Jens Axboe <axboe@fb.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH 7/8] mq-deadline: add blk-mq adaptation of the deadline IO scheduler |
| Date | 2017-01-20 15:30 +0100 |
| Message-ID | <t1Imt-8mw-19@gated-at.bofh.it> (permalink) |
| References | <sPaTf-2bJ-5@gated-at.bofh.it> <sPaTf-2bJ-13@gated-at.bofh.it> <t1HgK-7Iz-5@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Fri, Jan 20 2017, Paolo Valente wrote: > > > Il giorno 17 dic 2016, alle ore 01:12, Jens Axboe <axboe@fb.com> ha scritto: > > > > This is basically identical to deadline-iosched, except it registers > > as a MQ capable scheduler. This is still a single queue design. > > > > Jens, > no spin_lock_irq* in the code. So, also request dispatches are > guaranteed to never be executed in IRQ context? I'm asking this > question to understand whether I'm missing something that, even in > BFQ, would somehow allow me to not disable irqs in critical sections, > even if there is the slice_idle-expiration handler. Be patient with > my ignorance. Yes, dispatches will never happen from IRQ context. blk-mq was designed so we didn't have to use irq disabling locks. That said, certain parts of the API can be called from IRQ context. put_request and the completion parts, for instance. But blk-mq doesn't need to grab any locks there, and neither does mq-deadline. This might be different from bfq. lockdep can be a big help there. -- Jens Axboe
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
Re: [PATCH 7/8] mq-deadline: add blk-mq adaptation of the deadline IO scheduler Paolo Valente <paolo.valente@linaro.org> - 2017-01-20 14:20 +0100 Re: [PATCH 7/8] mq-deadline: add blk-mq adaptation of the deadline IO scheduler Jens Axboe <axboe@fb.com> - 2017-01-20 15:30 +0100
csiph-web