Re: [PATCH v6 12/23] virt: Introduce steal monitor driver
From: Yury Norov
Date: Mon Jul 06 2026 - 16:06:49 EST
On Mon, Jul 06, 2026 at 01:54:05PM +0530, Shrikanth Hegde wrote:
>
>
> On 7/3/26 11:57 PM, Yury Norov wrote:
> > On Fri, Jul 03, 2026 at 02:20:32PM -0400, Yury Norov wrote:
> > > On Wed, Jul 01, 2026 at 07:46:43PM +0530, Shrikanth Hegde wrote:
> > > > Introduce a new driver in virt named steal_monitor. This driver
> > > > will compute the steal time and drive the policy decisions of preferred
> > > > CPU state.
> > > >
> > > > More on it can be found in the Documentation/driver-api/steal-monitor.rst
> > > > Introduce the skeleton code first.
> > > >
> > > > There is no new kconfig. It depends on CONFIG_PREFERRED_CPU.
> > > > - If CONFIG_PREFERRED_CPU=y, it gets compiled as a module. It is not
> > > > loaded by default.
> >
> > What if I've got my own monitor, and don't need this one? Please add a
> > way to not compile it, even if CONFIG_PREFERRED_CPU is enabled.
> >
>
> You mean make a new config like VIRT_MONITOR depend on CONFIG_PREFERRED_CPU and
> make it as default n?
>
> Can we defer this until such a new monitor is needed?
> We will in state where CONFIG_PREFERRED_CPU=y & VIRT_MONITOR=n.
I think the VIRT_MONITOR should select PREFERRED_CPU. Whether
PREFERRED_CPU should be enabled without an in-tree driver using it -
IDK. Probably yes.
Enabling some random driver, and even worse overriding user
preferences looks questionable, at least.
I'm one of those who build VMs with the localyes config, particularly
because it decouples me from rootfs headache. So please let me just
compile-in your monitor, if I want.