Re: [PATCH RFC - TAKE TWO - 00/12] New version of the BFQ I/O Scheduler

[Paolo Valente]

Il giorno 19/giu/2014, alle ore 04:29, Jens Axboe <axboe@xxxxxxxxx> ha scritto:

> On 2014-06-18 18:46, Tejun Heo wrote:
>> Hello,
>> 
>> On Tue, Jun 17, 2014 at 05:55:57PM +0200, Paolo Valente wrote:
>>> In general, with both a smooth but messy and a sharp but clean
>>> transformation, there seems to be the following common problems:
>>> 
>>> 1) The main benefits highlighted by Jens, i.e., being able to move
>>> back and forth and easily understand what works and what does not,
>>> seem to be lost, because, with both solutions, intermediate versions
>>> would likely have a worse performance than the current version of
>>> cfq.
>> 
>> So, the perfectly smooth and performant transformation is possible,
>> it'd be great, but I don't really think that'd be the case.  My
>> opinion is that if the infrastructure pieces can be mostly maintained
>> while making logical gradual steps it should be fine.  ie. pick
>> whatever strategy which seems executable, chop down the pieces which
>> get in the way (ie. tear down all the cfq heuristics if you have to),
>> transform the base and then build things on top again.  Ensuring that
>> each step is logical and keeps working should give us enough safety
>> net, IMO.
>> 
>> Jens, what do you think?
> 
> I was thinking the same - strip CFQ back down, getting rid of the heuristics, then go forward to BFQ. That should be feasible. You need to find the common core first.

OK, I will try exactly this approach (hoping not to have misunderstood anything).
Here is, very briefly, the strategy I am thinking about:
1) In a first, only-destructive phase, bring CFQ back, more or less, to its state
at the time when BFQ was forked initially, and justify the removal of every heuristic
and improvement. Depending on how many patches come out during this phase,
possibly pack them into a first, separate patch series.
2) In a second, only-constructive phase: (a) turn the stripped-down version of CFQ into
a flat BFQ-v0, (b) turn the latter into BFQ-v0, and, finally, (c) progressively turn BFQ-v0
into the last version of BFQ, through the previously-submitted patches. Of course after
fixing and improving all the involved patches according to the suggestions and corrections
of Tejun.

I will wait shortly for a possible feedback on this proposal, and, then, if nothing has still to be
changed or refined, silently start the process.

> 
>>> 2) bfq, on one side, does not export some of the sysfs parameters of
>>> cfq, such as slice_sync, and, on the other side, uses other common
>>> parameters in a different way. For example, bfq turns I/O priorities
>>> into throughput shares in a different way than cfq does. As a
>>> consequence, existing configurations may break or behave in
>>> unexpected ways.
>> 
>> This is why I hate exposing internal knobs without layering proper
>> semantic interpretation on top.  It ends up creating unnecessary
>> lock-in effect too often just to serve some esoteric cases which
>> aren't all that useful.  For knobs which don't make any sense for the
>> new scheduler, the appropriate thing to do would be just making them
>> noop and generate a warning message when it's written to.
>> 
>> As for behavior change for existing users, any change to scheduler
>> does that.  I don't think it's practical to avoid any changes for that
>> reason.  I think there already is a pretty solid platform to base
>> things on and the way forward is making the changes and iterating as
>> testing goes on and issues get reported.
> 
> Completely agree, don't worry about that. It's not like we advertise hard guarantees on the priorities right now, for instance, so as long as the end result isn't orders of magnitude different for the classes/levels, then it'll likely be good enough.
> 
> Ditto on the sysfs files, as some of those are likely fairly widely used. But if we warn and do nothing, then that'll allow us to sort out popular uses of it before we (later on) remove the files.

Great, thanks. BTW, most of the ‘internal’ parameters inappropriately exposed by BFQ,
as noted by Tejun, were exposed just because we forgot to remove them while turning
the testing version of BFQ into the submitted one. Sorry about that.

Thanks,
Paolo

> 
> -- 
> Jens Axboe


--
Paolo Valente                                                 
Algogroup
Dipartimento di Fisica, Informatica e Matematica		
Via Campi, 213/B
41125 Modena - Italy        				  
homepage:  http://algogroup.unimore.it/people/paolo/

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/