On Wed, 4 Mar 2026 13:15:29 +0300 Gutierrez Asier <[email protected]> wrote:
> Hi SeongJae! > > Nice idea for dynamic environments. Thank you :) > > On 3/4/2026 7:41 AM, SeongJae Park wrote: > > Aim-oriented DAMOS quota auto-tuning uses a single tuning algorithm. > > The algorithm is designed to find a quota value that should be > > consistently kept for achieving the aimed goal for long term. It is > > useful and reliable at automatically operating systems that have dynamic > > environments in the long term. > > > > As always, however, no single algorithm fits all. When the environment > > has static characteristics or there are control towers in not only the > > kernel space but also the user space, the algorithm shows some > > limitations. In such environments, users want kernel work in a more > > short term deterministic way. Actually there were at least two reports > > [1,2] of such cases. > > > > Extend DAMOS quotas goal to support multiple quota tuning algorithms > > that users can select. Keep the current algorithm as the default one, > > to not break the old users. Also give it a name, "consist", as it is > > designed to "consistently" apply the DAMOS action. And introduce a new > > tuning algorithm, namely "temporal". It is designed to apply the DAMOS > > action only temporally, in a deterministic way. In more detail, as long > > as the goal is under-achieved, it uses the maximum quota available. > > Once the goal is over-achieved, it sets the quota zero. > > I'm not sure "temporal" is the best name for this type of behaviour. I agree there could be a better name. > > How about "by_score?". For example, "damos_goal_tune_esz_bp_by_score" and > DAMOS_QUOTA_GOAL_TUNER_BY_SCORE. And thank you for the suggestion! But... I don't think "by_score" is much better, because all tuners are assumed to, and actually do the tuning of the quota based on the score. Or, maybe you mean it makes non-zero quota only until the score becomes the goal? That makes sense, but again, in a sense, that's same for "consistent" tuner. Naming is difficult... I was also thinking about a few more names, but my conclusion after the self discussion was that some of ambitious names are inevitable here. Otherwise, the name will be too long. I therefore picked the shortest and simplest ones on my list, which at least contrasts the current two tuners. I agree that could still be difficult to understand. But as long as there is a good documentation, I think difficult-to-understnd names that encourage users to read the document is ok and might even be better in some cases. I'm of course open to other suggestions. Thanks, SJ [...]
