Re: [PATCH v5 00/16] x86/resctrl: Add kernel-mode (e.g., PLZA) support to the resctrl subsystem

[Chen Yu]

Hi Babu,

On Mon, Sep 21, 2026 at 02:27:45PM -0500, Babu Moger wrote:
> 
> Hi Chenyu,
> 
> On 9/20/26 22:22, Chen Yu wrote:
> > Hi Babu,
> > 
> > On Wed, Aug 26, 2026 at 02:32:14PM -0500, Babu Moger wrote:
> > > 
> > > 
> > >    # Create a CTRL_MON group and associate kernel-mode allocation with it.
> > >    # mkdir ctrl1
> > >    # echo "assign_global_enable_per_cpu:ctrl=assign;mon=inherit;group=ctrl1//" \
> > >            > info/kernel_mode
> > >    # cat info/kernel_mode
> > >    inherit_user
> > >    [assign_global_enable_per_cpu:ctrl=assign;mon=inherit;group=ctrl1//]
> > > 
> > >    # kmode_cpus and kmode_cpus_list are visible only on the associated group.
> > >    # ls ctrl1/kmode_cpus*
> > >    ctrl1/kmode_cpus  ctrl1/kmode_cpus_list
> > > 
> > 
> > Just curious, would the other existing files like "tasks" be exposed under ctrl1?
> > If this ctrl1 is used only for "kernel space" mode, would the schemata of ctrl1 be
> > shared by all tasks in the system? That is to say, it seems that there is no need to
> > expose "tasks" under ctrl1. Should we hide "tasks" for the kernel group? Please
> > correct me if I misunderstood.
> 
> No, I don't think we should hide the tasks interface here. It provides the
> option to use a group in a mixed mode.
> 
> # mkdir ctrl1
> # cd ctrl1
> # echo "1,2,3" > tasks
> 
> At this point, PIDs 1, 2, and 3 will use the schemata from ctrl1, regardless
> of which CPU they are running on. They will use the same limits in both user
> and kernel mode.
> 
> # echo "assign_global_enable_per_cpu:ctrl=assign;mon=inherit;group=ctrl1//"
> \
>           > info/kernel_mode
> 
> After this, all CPUs in the system will use the schemata from ctrl1 while
> running in kernel mode, including when executing on behalf of PIDs 1, 2, and
> 3.
> 
> Essentially, this provides the flexibility to run in a mixed mode.
>

I see, a single group can be used both for regular resource control and global kernel resource
control. Thanks for this explanation.

thanks,
Chenyu