Re: [PATCH v7 10/12] virt/steal_monitor: Provide functions for managing steal values

[Yury Norov]

On Mon, Jul 13, 2026 at 10:43:15AM +0530, Shrikanth Hegde wrote:
> Hi Yury,
> 
> On 7/11/26 1:30 AM, Yury Norov wrote:

...

> > I think it should return status: if the function can't disable CPUs
> > now, it would be a good hint for the caller that it would be useless
> > to call it again.
> > 
> > You may keep status in struct steal_monitor like:
> > 
> >          if (steal_ratio > sm_core_ctx.high_threshold)  {
> >                  if (sm_core_ctx->status | CANT_DECREASE) {
> >                          pr_something();
> >                  else
> >                          sm_core_ctx->status = decrease();
> > 
> > It would be a good hint to user that he has the driver misconfigured,
> > and save the driver extra work. Same for increase().
> > 
> 
> I thought about the extra work in function, but doesn't happen too often IMO.

10ms is the shortest possible interval, 100 times in a second.

> Also, it is specially not a misconfiguration for increase.
> So i have kept it stateless for the below reason.
> 
> - Under typical operation of this driver, user will enable it once.
> - Once enabled, user will use their VM as usual.
> - Majority of the time the steal time will be less.
> - workload are bursty in nature.

Not necessarily.

> - Occasionally many VM will have high utilization and there will be steal time.
>   This lasts for sometime.
> - After workload completes, steal time goes low again.
> - Cycle could repeat after extended low steal time duration.
> 
> So when the steal time is low, though driver is enabled, doesn't mean it
> is mis-configured. Just that there is contention and driver has nothing to
> do. So, adding print there could easily consume the console.
> 
> Similarly, there could situations, where decrease cannot happen though there is
> high steal time, Though they are corner cases.

OK, that makes sense. If one needs to fine-tune the driver's
thresholds, he'd monitor the preferred cpumasks statistics.

> For example,
> - one small/few VMs have not enabled the driver. steal time could be high, but this
>   VM has already down to one core. It can't decrease any further.
> - Though all VMs have enabled the feature, but task running is not FAIR class. Though
>   steal time shows high.
> 
> Hitting only one core or all cores isn't necessarily a misconfiguration.
> It is a possible behavior during severe contention or complete idle system.
> 
> we need to continuously monitor steal time so that it can expand/contract the
> based on current situation. If we stop calling the functions, natural expand/contract
> will not happen. There is no interrupt which arrives due to high/low steal time where
> we can kick start the driver again. Also it is a difficult ask for user to keep enabling
> or disabling the driver.
> 
> Since this can be called at minimal once in 10ms, I guess we can incur the additional
> overheads to keep the logic simple and stateless. What do you think?

OK, it's your design.

> PS: I will remove that additional SM_DIR as you suggested in other reply. That keeps
> it all stateless.