Re: [Patch v4 00/22] Cache aware scheduling

Chen, Yu C
2026-04-23T16:49:19Z

On 4/23/2026 11:06 PM, Qais Yousef wrote:
> On 04/21/26 13:57, Tim Chen wrote:
>> On Tue, 2026-04-21 at 01:34 +0100, Qais Yousef wrote:
>>> On 04/20/26 17:01, Chen, Yu C wrote:
>>>> On 4/16/2026 8:27 AM, Qais Yousef wrote:
>>>>> On 04/01/26 14:52, Tim Chen wrote:
>>>>

[ ... ]

>>>> I suppose there are two scenarios. The first is enabling/disabling
>>>> aggregation
>>>> for a group of tasks, and the second is task tagging. For the first
>>>> scenario,
>>>> this can be applied either process-wide or cgroup-wide by providing a flag,
>>>
>>> Cgroup-wide tagging doesn't make sense IMO. Process-wide yes.
>>>
>>
>> I think this depends on the usage scenario. In private discussion with
>> Vern from Tencent, he mentioned that such a cgroup based tagging is useful for them.
>
> We all want ponies :)
>
> I think this needs a why. It doesn't make sense to group procsses in general.
> It seems this requirement is tied to elaborate setup to force the kernel to
> deal with this elaborate setup in a generic manner.

Using cgroup tagging appears to be a trade-off intended to reduce users'
overhead from interface migration. Based on feedback from several cloud
providers (Vern, please correct me if my understanding is wrong),
cgroups are the basic unit for infrastructure construction:
there could be a large process with N threads: N/2 of them
are assigned to cgroup1, and the remaining N/2 to cgroup2.
Updating the attributes associated with a cgroup is
straightforward - using process-based aggregation might not work
for this scenario - using task-based aggregation would require to
re-write the mid-layer.

>
> Anyway with the tagging approach we can easily allow process level LLC sharing
> via simple description like
>
> // shared cookie definition
> {
> "WEB_SERVICE_COOKIE": [ "nginx", "postgresql"],
> "TRANSCODING_COOKIE": [ "decoder", "encoder"]
> }
>
> Which simply tell the utility to reuse the cookie for these processes using the
> key as a unique identifier.
>
> By the way, cookie generation might need kernel help to create a unique id.
>
> Still, if someone wants such elaborate setup the first thing to suggest is
> static portioning via cpuset. Do you know why this is not sufficient?

I suppose it is because the admin want a high system utilization by
mixing latency-sensitive tasks and batch tasks together to share the
CPU resource. Using cpuset to isolate them might bring lower utilization.

thanks,
Chenyu