Hello Song and I apology for late reply. I understand the motivation for the headroom attribute is to achieve side load throttling before the CPU is fully saturated since your measurements show that something else gets saturated earlier than CPU and causes grow of the observed latency. The second aspect of the headroom knob, i.e. dynamic partitioning of the CPU resource is IMO something which we already have thanks to cpu.weight. As you wrote, plain cpu.weight of workloads didn't work for you, so I think it'd be worth figuring out what is the resource whose saturation affects the overall observed latency and see if a protection/weights on that resource can be set (or implemented). On Tue, May 21, 2019 at 04:27:02PM +0000, Song Liu <songliubraving@xxxxxx> wrote: > The overall latency (or wall latency) contains: > > (1) cpu time, which is (a) and (d) in the loop above; How do you measure this CPU time? Does it include time spent in the kernel? (Or can there be anything else unaccounted for in the following calculations?) > (2) time waiting for data, which is (b); Is your assumption of this being constant supported by the measurements? The last note is regarding semantics of the headroom knob, I'm not sure it fits well into the weight^allocation^limit^protection model. It seems to me that it's crafted to satisfy the division to one main workload and side workload, however, the concept doesn't generalize well to arbitrary number of siblings (e.g. two cgroups with same headroom, third with less, who is winning?). HTH, Michal
