Messages in this thread | | | Subject | Re: [PATCH 08/10] blkcg: implement blk-iocost | From | Paolo Valente <> | Date | Fri, 1 Nov 2019 17:56:48 +0100 |
| |
> Il giorno 1 nov 2019, alle ore 17:15, Michal Koutný <mkoutny@suse.com> ha scritto: > > Hello >
Hi Michal,
> (I realize it's likely late for the remark but I'd like to bring it up > anyway.) > > On Mon, Oct 14, 2019 at 08:36:43AM -0700, Tejun Heo <tj@kernel.org> wrote: >> We likely can talk on the subject >> for a really long time probalby because there's no clearly technically >> better choice here, so... > I agree with you that functionally the two options are equal and also > from configuration POV they seem both sensible. > > I checked where BFQ stores its per-device parameters and its under the > sysfs directory of given device's iosched directory. So from the user > perspective it'd be more consistent if all similar tunables resided > under that location. > > (OTOH, I admit I'm not that familiar with block layer internals to > identify the overlap between IO scheduler and IO controller.) >
If useful for you to know, BFQ parameters are not meant to changed (apart from the low_latency tunable, if one wants full control on weights). Parameters are a testing aid, to use in case of an anomaly. After solving the anomaly, default values should be used again.
Thanks, Paolo
>> Yeah, it's kinda unfortunate that it requires this many parameters but >> at least my opinion is that that's reflecting the inherent >> complexities of the underlying devices and how workloads interact with >> them. > After I learnt about the existence of BFQ tunables, I'm no longer > concerned by the complexity of the parameter space. > > Thanks for the explanations of QoS purpose. > >> For QoS parameters, Andy is currently working on a method to determine >> the set of parametesr which are at the edge of total work cliff - >> ie. the point where tighetning QoS params further starts reducing the >> total amount of work the device can do significantly. > The QoS description in the Documentation/ describes the interpretation > of the individual parameters, however, this purpose and how it works was > not clear to be from that. I think the QoS policy would deserve similar > description in the Documentation/. > >> Nothing can issue IOs indefinitely without some of them completing and >> the total amount of work a workload can do is conjoined with the >> completion latencies. [...] > I may reply to this point later. However, if that provably works, I'm > likely missing something in my understanding, so that'd be irrelevant. > > Cheers, > Michal
| |