Re: [PATCH] lib/cpumask: Boot option to disable tasks distribution within cpumask

[Ankit Jain]

> On 02-May-2024, at 1:39 PM, Ankit Jain <ankit-aj.jain@xxxxxxxxxxxx> wrote:
> 
> On Tue, Apr 30, 2024 at 11:23:07AM -0700, Yury Norov wrote:
>> On Tue, Apr 30, 2024 at 02:34:31PM +0530, Ankit Jain wrote:
>>> commit 46a87b3851f0 ("sched/core: Distribute tasks within affinity masks")
>>> and commit 14e292f8d453 ("sched,rt: Use cpumask_any*_distribute()")
>>> introduced the logic to distribute the tasks within cpumask upon initial
>>> wakeup.
>> 
>> So let's add the authors in CC list?
>> 
>>> For Telco RAN deployments, isolcpus are a necessity to cater to
>>> the requirement of low latency applications. These isolcpus are generally
>>> tickless so that high priority SCHED_FIFO tasks can execute without any
>>> OS jitter. Since load balancing is disabled on isocpus, any task
>>> which gets placed on these CPUs can not be migrated on its own.
>>> For RT applications to execute on isolcpus, a guaranteed kubernetes pod
>>> with all isolcpus becomes the requirement and these RT applications are
>>> affine to execute on a specific isolcpu within the kubernetes pod.
>>> However, there may be some non-RT tasks which could also schedule in the
>>> same kubernetes pod without being affine to any specific CPU(inherits the
>>> pod cpuset affinity).
>> 
>> OK... It looks like adding scheduler maintainers is also a necessity to
>> cater here...
> 
> So 14e292f8d453 is very specifically only using sched_domain_span(), and
> if you're using partitioned CPUs they should not show up there.
> 
> As to 46a87b3851f0, if you're explicitly creating tasks with an affinity
> masks that spans your partition then you're getting what you ask for.
> 
> In fact, I already explained this to you earlier, so why are you
> suggesting horrible hacks again? This behaviour toggle you suggest is
> absolutely unacceptable.
> 
> I even explained what the problem was and where to look for solutions.
> 
> https://www.google.com/url?q=https://lkml.kernel.org/r/20231011135238.GG6337@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&source=gmail-imap&ust=1715244235000000&usg=AOvVaw03JVPjd7QleOP3JrOjP8pO


Hi Peter,

Apologies for not trying out the solution you suggested earlier. I will test this
solution for our use case and share the result.

Thanks,
Ankit