public inbox for linux-s390@vger.kernel.org
 help / color / mirror / Atom feed
From: Tobias Huschle <huschle@linux.ibm.com>
To: Shrikanth Hegde <sshegde@linux.ibm.com>
Cc: mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com,
	vincent.guittot@linaro.org, dietmar.eggemann@arm.com,
	rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de,
	vschneid@redhat.com, linuxppc-dev@lists.ozlabs.org,
	linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v2 1/3] sched/fair: introduce new scheduler group type group_parked
Date: Thu, 20 Feb 2025 11:53:32 +0100	[thread overview]
Message-ID: <e2495b3a-81c5-4238-b766-2ab6e892b6bf@linux.ibm.com> (raw)
In-Reply-To: <ee74de65-1b9d-4c40-aa57-52682801260a@linux.ibm.com>



On 18/02/2025 06:44, Shrikanth Hegde wrote:
[...]
>> @@ -1352,6 +1352,9 @@ bool sched_can_stop_tick(struct rq *rq)
>>       if (rq->cfs.h_nr_queued > 1)
>>           return false;
>> +    if (rq->cfs.nr_running > 0 && arch_cpu_parked(cpu_of(rq)))
>> +        return false;
>> +
> 
> you mean rq->cfs.h_nr_queued or rq->nr_running ?
> 

cfs.h_nr_queued is probably more sensible, will use that.

[...]
>> @@ -11259,6 +11293,8 @@ static inline void calculate_imbalance(struct 
>> lb_env *env, struct sd_lb_stats *s
>>    * avg_load : Only if imbalance is significant enough.
>>    * nr_idle :  dst_cpu is not busy and the number of idle CPUs is quite
>>    *            different in groups.
>> + * nr_task :  balancing can go either way depending on the number of 
>> running tasks
>> + *            per group
>>    */
> 
> This comment on nr_task can be removed as it is not present in the list.
> 

Consider it gone.

[...]
>> @@ -11766,7 +11822,7 @@ static int sched_balance_rq(int this_cpu, 
>> struct rq *this_rq,
>>       ld_moved = 0;
>>       /* Clear this flag as soon as we find a pullable task */
>>       env.flags |= LBF_ALL_PINNED;
>> -    if (busiest->nr_running > 1) {
>> +    if (busiest->nr_running > 1 || arch_cpu_parked(busiest->cpu)) {
> 
> Since there is reliance on active balance if there is single task, it 
> think above isn't needed. Is there any usecase for it?
>

Seems to work without that check. I have no particular use case in mind.

>>           /*
>>            * Attempt to move tasks. If sched_balance_find_src_group 
>> has found
>>            * an imbalance but busiest->nr_running <= 1, the group is
>> @@ -12356,6 +12412,11 @@ static void nohz_balancer_kick(struct rq *rq)
>>       if (time_before(now, nohz.next_balance))
>>           goto out;
>> +    if (!idle_cpu(rq->cpu)) {
>> +        flags = NOHZ_STATS_KICK | NOHZ_BALANCE_KICK;
>> +        goto out;
>> +    }
>> +
> 
> This could be agrressive. Note when the code comes here, it is not idle. 
> It would bail out early if it is idle.
> 

It seems like we can do without this one as well.

>>       if (rq->nr_running >= 2) {
>>           flags = NOHZ_STATS_KICK | NOHZ_BALANCE_KICK;
>>           goto out;
>> @@ -12767,6 +12828,9 @@ static int sched_balance_newidle(struct rq 
>> *this_rq, struct rq_flags *rf)
>>       update_misfit_status(NULL, this_rq);
>> +    if (arch_cpu_parked(this_cpu))
>> +        return 0;
>> +
>>       /*
>>        * There is a task waiting to run. No need to search for one.
>>        * Return 0; the task will be enqueued when switching to idle.
>> diff --git a/kernel/sched/syscalls.c b/kernel/sched/syscalls.c
>> index 456d339be98f..7efd76a30be7 100644
>> --- a/kernel/sched/syscalls.c
>> +++ b/kernel/sched/syscalls.c
>> @@ -214,6 +214,9 @@ int idle_cpu(int cpu)
>>           return 0;
>>   #endif
>> +    if (arch_cpu_parked(cpu))
>> +        return 0;
>> +
>>       return 1;
>>   }
> 


  reply	other threads:[~2025-02-20 10:53 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-17 11:32 [RFC PATCH v2 0/3] sched/fair: introduce new scheduler group type group_parked Tobias Huschle
2025-02-17 11:32 ` [RFC PATCH v2 1/3] " Tobias Huschle
2025-02-18  5:44   ` Shrikanth Hegde
2025-02-20 10:53     ` Tobias Huschle [this message]
2025-02-17 11:32 ` [RFC PATCH v2 2/3] sched/fair: adapt scheduler group weight and capacity for parked CPUs Tobias Huschle
2025-02-17 11:32 ` [RFC PATCH v2 3/3] s390/topology: Add initial implementation for selection of " Tobias Huschle
2025-02-18  5:58 ` [RFC PATCH v2 0/3] sched/fair: introduce new scheduler group type group_parked Shrikanth Hegde
2025-02-20 10:55   ` Tobias Huschle
2025-02-25 10:33     ` Shrikanth Hegde

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e2495b3a-81c5-4238-b766-2ab6e892b6bf@linux.ibm.com \
    --to=huschle@linux.ibm.com \
    --cc=bsegall@google.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=sshegde@linux.ibm.com \
    --cc=vincent.guittot@linaro.org \
    --cc=vschneid@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox