> Il giorno 1 nov 2019, alle ore 17:15, Michal Koutný <mkoutny@xxxxxxxx> 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@xxxxxxxxxx> 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
