From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 48418358367 for ; Thu, 4 Jun 2026 09:44:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.163.158.5 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780566259; cv=none; b=vFJ/1QZUrIv+rS7gAap35sDMrdtuZnMspkUBqluH6gS+0lIqq/NRIsOyx5RMDIrzbofTtkieEZKtnR8olMjSV+Cp1/x19KO76tjy1TLpAM77Ay8/yE57zu4RGn8XZoHO07MkV1x/n61GkNWKK94st+FUxGju1azU2HQoVyRHXdQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780566259; c=relaxed/simple; bh=Pv8l7iTKzO6q24DCGxiBR/R/BjH2pR8sTj5AOPNiZFI=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=nThF556qdWG6kzjmvYejxDOYv5A3jRsOlj5t2sqb2vlDR8H2Y8gkOIl/tnuH7V8wxEZwXqTnY4PLgFnNiUzyolOEQyzpB5NoPyj4/j/NTco9Y2xlDcH7z2SorBVHwtkHOZSCMey9EEo1SmNkJWuhPdGr9bCLLoW/edf04KNr9jo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.ibm.com; spf=pass smtp.mailfrom=linux.ibm.com; dkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com header.b=Nq4flwIj; arc=none smtp.client-ip=148.163.158.5 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.ibm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.ibm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com header.b="Nq4flwIj" Received: from pps.filterd (m0356516.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 6549bqEh1956882; Thu, 4 Jun 2026 09:43:56 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=pp1; bh=TOb6XJ 8uvnof447bqVSdQrmeuswLoS5+EL4Tj/roD/I=; b=Nq4flwIjLOFj/s1+6SLvRH tx9SZ1RL4H4uO8QtmPEA9seV2cVnjGIEQicUWMgn/z06mQxVahgo8E22TJze2K7W m5OIN/06NtnE1O+b5uvJ6D11+T/R3amUNjQ2Fi5rBRNa23kMv2+03RdQdTz3q3SE +RBdqTKsuqGqhqxvBcW4/3bvnuCPJu/v88a+e6Wxe9vrdKFeZz4laPs7G7QT2AFK lR+5VZzrvhjUpC9Nn4I5flcFRsZ4b8D6zJApw87WCMRs9svZYppaUv6uRhhj4LA7 ukfYXnwaXhTS3ug/6QpNCymFJEcfik99+2xB5z8fJnYqLfdPVnh2fAKDPkAbA4Yg == Received: from ppma12.dal12v.mail.ibm.com (dc.9e.1632.ip4.static.sl-reverse.com [50.22.158.220]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4efnahxr9g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 04 Jun 2026 09:43:55 +0000 (GMT) Received: from pps.filterd (ppma12.dal12v.mail.ibm.com [127.0.0.1]) by ppma12.dal12v.mail.ibm.com (8.18.1.7/8.18.1.7) with ESMTP id 6549d57Y029028; Thu, 4 Jun 2026 09:43:54 GMT Received: from smtprelay05.fra02v.mail.ibm.com ([9.218.2.225]) by ppma12.dal12v.mail.ibm.com (PPS) with ESMTPS id 4ega7qmn32-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 04 Jun 2026 09:43:54 +0000 (GMT) Received: from smtpav02.fra02v.mail.ibm.com (smtpav02.fra02v.mail.ibm.com [10.20.54.101]) by smtprelay05.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 6549hpf148955718 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 4 Jun 2026 09:43:51 GMT Received: from smtpav02.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id F3C922004B; Thu, 4 Jun 2026 09:43:50 +0000 (GMT) Received: from smtpav02.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6DCE520043; Thu, 4 Jun 2026 09:43:44 +0000 (GMT) Received: from [9.123.5.233] (unknown [9.123.5.233]) by smtpav02.fra02v.mail.ibm.com (Postfix) with ESMTP; Thu, 4 Jun 2026 09:43:44 +0000 (GMT) Message-ID: Date: Thu, 4 Jun 2026 15:13:43 +0530 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 11/20] sched/core: Push current task from non preferred CPU To: K Prateek Nayak , linux-kernel@vger.kernel.org, mingo@kernel.org, peterz@infradead.org, juri.lelli@redhat.com, vincent.guittot@linaro.org, yury.norov@gmail.com, iii@linux.ibm.com Cc: tglx@kernel.org, gregkh@linuxfoundation.org, pbonzini@redhat.com, seanjc@google.com, vschneid@redhat.com, huschle@linux.ibm.com, rostedt@goodmis.org, dietmar.eggemann@arm.com, mgorman@suse.de, bsegall@google.com, maddy@linux.ibm.com, srikar@linux.ibm.com, hdanton@sina.com, chleroy@kernel.org, vineeth@bitbyteword.org, frederic@kernel.org, arighi@nvidia.com, pauld@redhat.com, christian.loehle@arm.com, tj@kernel.org, tommaso.cucinotta@gmail.com, maz@kernel.org, rafael@kernel.org References: <20260514152204.481115-1-sshegde@linux.ibm.com> <20260514152204.481115-12-sshegde@linux.ibm.com> <83032c54-0cdf-429c-bcff-bba4e5b2002b@amd.com> From: Shrikanth Hegde Content-Language: en-US In-Reply-To: <83032c54-0cdf-429c-bcff-bba4e5b2002b@amd.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-Reinject: loops=2 maxloops=12 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwNjA0MDA5MiBTYWx0ZWRfXyj1do1X0byhn zP00+h2HxiS5SC8GQLgZMgZ00oO3/tSoWOC97iylyWsrrv+3am7tRGIe2E54daTk1fdVSGgXl2X DkeVlg/WZUkVQ8TwTFYxzRi9J5FKV5Y5tvT5O8tbKMRkOsF9Tpv0sSKnVap354OavMatMURL12a 2zajCa2bxQ2ANYrxw7EZJYalV6WdnelsBHXE2Lz/G4jnaVuMUAVCOZF5HKnwa6pz9EnPTGVUY1g BUCcAAEryAnTEnSI7LNoM5mBAii8Dran5R8wuuJmY6Og5eX5v35foR9jFAPfLgpKETmdslt02wi Qc0P4BNw+pWOGeBR6zphGeWYcK4m93rHt0T3WgVLYfckjjOWknP2sT5UoCDwKBHKgxGFRucOy2n bEyUcvRFLCCn1NiXCddx/SgUZqrZTaV6bC5vtso5mL4A3qxRh+mF+CYARLrTdodT+ltJzILUDZ1 TjGnWfZZc4l86cg7bBg== X-Proofpoint-ORIG-GUID: Xnm30NukR_e0kszQlMsyKT37ZvZqUKCD X-Authority-Analysis: v=2.4 cv=cOzQdFeN c=1 sm=1 tr=0 ts=6a2148dc cx=c_pps a=bLidbwmWQ0KltjZqbj+ezA==:117 a=bLidbwmWQ0KltjZqbj+ezA==:17 a=IkcTkHD0fZMA:10 a=FelO9ux0wxsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=RnoormkPH1_aCDwRdu11:22 a=Y2IxJ9c9Rs8Kov3niI8_:22 a=Y8BFBQI2gDsSKaUvnsMA:9 a=QEXdDO2ut3YA:10 X-Proofpoint-GUID: wej3vhoA_tpaljk-cJ5aTVdCVmtn_Lj9 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.125,FMLib:17.12.100.49 definitions=2026-06-04_03,2026-05-28_03,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1015 impostorscore=0 lowpriorityscore=0 spamscore=0 bulkscore=0 malwarescore=0 phishscore=0 suspectscore=0 priorityscore=1501 adultscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2605210000 definitions=main-2606040092 Hi Prateek. On 6/4/26 12:28 PM, K Prateek Nayak wrote: > Hello Shrikanth, > > On 5/14/2026 8:51 PM, Shrikanth Hegde wrote: >> diff --git a/kernel/sched/core.c b/kernel/sched/core.c >> index 86fa4bfaead0..508773e71929 100644 >> --- a/kernel/sched/core.c >> +++ b/kernel/sched/core.c >> @@ -5678,6 +5678,9 @@ void sched_tick(void) >> unsigned long hw_pressure; >> u64 resched_latency; >> >> + if (!cpu_preferred(cpu)) >> + sched_push_current_non_preferred_cpu(rq); >> + > > Is there a reason why we don't do a bulk move of all the queued tasks at > once? > > Is it simply for the latency reason or could it lead to too many task > movements if the CPU frequently transitions in and out of the preferred > mask ? It was simplicity of moving one at a time and latency associated with moving many. > >> if (housekeeping_cpu(cpu, HK_TYPE_KERNEL_NOISE)) >> arch_scale_freq_tick(); >> >> @@ -11263,3 +11266,87 @@ void sched_change_end(struct sched_change_ctx *ctx) >> p->sched_class->prio_changed(rq, p, ctx->prio); >> } >> } >> + >> +#ifdef CONFIG_PREFERRED_CPU >> +/* npc - non preferred CPU */ >> +static DEFINE_PER_CPU(struct cpu_stop_work, npc_push_task_work); >> + >> +static int sched_non_preferred_cpu_push_stop(void *arg) >> +{ >> + struct task_struct *p = arg; >> + struct rq *rq = this_rq(); >> + struct rq_flags rf; >> + int cpu; > > I think we should do that sanity check for cpu_preferred() here instead > of doing it back to back when sched_push_current_non_preferred_cpu() is > called from the tick handler. > Ok. >> + >> + raw_spin_lock_irq(&p->pi_lock); >> + rq_lock(rq, &rf); >> + rq->push_task_work_done = 0; >> + >> + update_rq_clock(rq); >> + >> + if (task_rq(p) == rq && task_on_rq_queued(p)) { >> + cpu = select_fallback_rq(rq->cpu, p); >> + rq = __migrate_task(rq, &rf, p, cpu); >> + } >> + >> + rq_unlock(rq, &rf); >> + raw_spin_unlock_irq(&p->pi_lock); >> + put_task_struct(p); >> + >> + return 0; >> +} >> + >> +/* >> + * Push the current task running on non-preferred CPU. >> + * Using this non preferred CPU will lead to more vCPU preemptions >> + * in the host. So it is better not to use this CPU. >> + * >> + * Since task is running, call a stopper to push the task out. This is >> + * similar to how task moves during hotplug. In select_fallback_rq a >> + * preferred CPU will be chosen and henceforth task shouldn't come back to >> + * this CPU again. >> + * >> + * Works for FAIR/RT class only >> + * >> + * If task is affined only non-preferred CPUs, it can't be moved out >> + */ >> +void sched_push_current_non_preferred_cpu(struct rq *rq) >> +{ >> + struct task_struct *push_task = rq->curr; >> + unsigned long flags; >> + struct rq_flags rf; >> + >> + /* sanity check */ >> + if (cpu_preferred(rq->cpu)) >> + return; >> + >> + /* Push only if it is FAIR/RT class */ >> + if (push_task->sched_class != &fair_sched_class && >> + push_task->sched_class != &rt_sched_class) >> + return; >> + >> + if (kthread_is_per_cpu(push_task) || >> + is_migration_disabled(push_task)) >> + return; >> + >> + /* Is there any preferred CPU in the affinity list */ >> + if (!task_has_preferred_cpus(push_task)) >> + return; > > I think there is some value to teach the __migrate_enable() path about > the preferred_cpu - that way, we don't end up with > __set_cpus_allowed_ptr_locked() putting a task on non-preferred > CPU by selecting it from: > > cpumask_any_and_distribute(cpu_valid_mask, ctx->new_mask); > > and affine_move_task() can handle cases where the task does a > migrate_enable() from a non-preferred CPU / changes affinity and can be > pushed out readily. Ok. will read more into this. > > I'll let Peter comment since that bit already very complicated and this > would be adding more to that already complicated machinery. > >> + >> + /* There is already a stopper thread for this. Dont race with it */ >> + if (rq->push_task_work_done == 1) >> + return; >> + >> + local_irq_save(flags); >> + >> + get_task_struct(push_task); >> + >> + rq_lock(rq, &rf); > > nit. the irqsave and rq_lock can use guards. alright. > >> + rq->push_task_work_done = 1; > > nit. > > Apart from task_has_preferred_cpus(), all the checks above have no > dependency on CONFIG_PREFERRED_CPU. Code will bloat for other users. Not many may want to set CONFIG_PREFERRED_CPU=y. That was the reason. > > Can we set some local indicator in sched_tick() within the rq_lock() section > to then schedule the stopper once we drop the rq_lock there? That way we > don't have to grab the rq_lock thrice in the worst case scenario where we > have to schedule the stopper. I didn't get you. can you explain? how are we grabbing rq_lock thrice? > >> + rq_unlock(rq, &rf); >> + >> + stop_one_cpu_nowait(rq->cpu, sched_non_preferred_cpu_push_stop, >> + push_task, this_cpu_ptr(&npc_push_task_work)); >> + local_irq_restore(flags); >> +} >> +#endif >