> Il giorno 19 dic 2016, alle ore 16:20, Jens Axboe <ax...@fb.com> ha scritto: > > On 12/19/2016 04:32 AM, Paolo Valente wrote: >> >>> Il giorno 17 dic 2016, alle ore 01:12, Jens Axboe <ax...@fb.com> ha scritto: >>> >>> This is version 4 of this patchset, version 3 was posted here: >>> >>> https://marc.info/?l=linux-block&m=148178513407631&w=2 >>> >>> From the discussion last time, I looked into the feasibility of having >>> two sets of tags for the same request pool, to avoid having to copy >>> some of the request fields at dispatch and completion time. To do that, >>> we'd have to replace the driver tag map(s) with our own, and augment >>> that with tag map(s) on the side representing the device queue depth. >>> Queuing IO with the scheduler would allocate from the new map, and >>> dispatching would acquire the "real" tag. We would need to change >>> drivers to do this, or add an extra indirection table to map a real >>> tag to the scheduler tag. We would also need a 1:1 mapping between >>> scheduler and hardware tag pools, or additional info to track it. >>> Unless someone can convince me otherwise, I think the current approach >>> is cleaner. >>> >>> I wasn't going to post v4 so soon, but I discovered a bug that led >>> to drastically decreased merging. Especially on rotating storage, >>> this release should be fast, and on par with the merging that we >>> get through the legacy schedulers. >>> >> >> I'm to modifying bfq. You mentioned other missing pieces to come. Do >> you already have an idea of what they are, so that I am somehow >> prepared to what won't work even if my changes are right? > > I'm mostly talking about elevator ops hooks that aren't there in the new > framework, but exist in the old one. There should be no hidden > surprises, if that's what you are worried about. > > On the ops side, the only ones I can think of are the activate and > deactivate, and those can be done in the dispatch_request hook for > activate, and put/requeue for deactivate. >
You mean that there is no conceptual problem in moving the code of the activate interface function into the dispatch function, and the code of the deactivate into the put_request? (for a requeue it is a little less clear to me, so one step at a time) Or am I missing something more complex? > Outside of that, some of them have been renamed, and some have been > collapsed (like activate/deactivate), and yet others again work a little > differently (like merging). See the mq-deadline conversion, and just > work through them one at the time. > That's how I'm proceeding, thanks. Thank you, Paolo > -- > Jens Axboe > > -- > To unsubscribe from this list: send the line "unsubscribe linux-block" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
