On Wed, Mar 13, 2019 at 03:59:54PM +0000, Patrick Bellasi wrote: > On 13-Mar 14:52, Peter Zijlstra wrote: > Because of backetization, we potentially end up tracking tasks with > different requested clamp values in the same bucket. > > For example, with 20% bucket size, we can have: > Task1: util_min=25% > Task2: util_min=35% > accounted in the same bucket. > > Given all that, what is to stop the bucket value to climbing to > > uclamp_bucket_value(+1)-1 and staying there (provided there's someone > > runnable)? > > Nothing... but that's an expected consequence of bucketization. No, it is not. > > Why are we doing this... ? > > You can either decide to: > > a) always boost tasks to just the bucket nominal value > thus always penalizing both Task1 and Task2 of the example above This is the expected behaviour. When was the last time your histogram did something like b? > b) always boost tasks to the bucket "max" value > thus always overboosting both Task1 and Task2 of the example above > > The solution above instead has a very good property: in systems > where you have only few and well defined clamp values we always > provide the exact boost. > > For example, if your system requires only 23% and 47% boost values > (totally random numbers), then you can always get the exact boost > required using just 3 bucksts or ~33% size each. > > In systems where you don't know which boost values you will have, you > can still defined the maximum overboost granularity you accept for > each task by just tuning the number of clamp groups. For example, with > 20 groups you can have a 5% max overboost. Maybe, but this is not a direct concequence of buckets, but an additional heuristic that might work well in this case. Maybe split this out in a separate patch? So start with the trivial bucket, and then do this change on top with the above few paragraphs as changelog?
