From nobody Wed Nov 27 00:22:35 2024 Received: from out-171.mta1.migadu.com (out-171.mta1.migadu.com [95.215.58.171]) (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 8D7C0156872 for ; Tue, 15 Oct 2024 11:15:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.171 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1728990947; cv=none; b=JnK2PM0H4ffbMDe/uVsYP5bLikghNDfD/OvtUzzQ0fq5aze9y+DSKSOXdaC5a8qMdE2ePAzc8QjRa6QRATgVZw+z6SHfECQeDXIYL7Hfs8AIvb8cv93fIHwETxrkl/AO6N4mHw2He9jNhhk1hZpiTHGY1ztRgMIx4yrppNxkLto= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1728990947; c=relaxed/simple; bh=ssmqsWWS81Vg0uTaEuJJktUUR/hioVtLY2g+nX1p7M8=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=CLLm9w4OyHj319M9B9zwyC59pObuEwF0OjrQaA2f2c8ZzKz6VTF/wdBvOUgmZhFBQtWnxKeuWtRmmOe9z4gUZB7gpgXC6kWTSRQ0JTiO+WDLp6//TP5Hl0nnyQkwZPmZGWxBmcMhRbRRKM669bXKrUg2EnkqY0YSePw05Cw8pOw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=hwE0CfQ6; arc=none smtp.client-ip=95.215.58.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="hwE0CfQ6" X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1728990942; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=ucQtvznDemSDFD+kG00/HvX/vw51G6Sc6n843ys325E=; b=hwE0CfQ6zx5RuK8fo0dhqMPrV6DJKqfw01P+l6q1t/dOTG+tcASPg4MJRgpNPZn1TUXss9 iUYoJrknU87/9Cy/XIxRrHNxfysegb3M1fRNJ/HpSadnin1HDRLKzfrnsyvb6CB/JmoCo+ lsgbqfDDgAVEbhdHFEbtPevoTIB+k/w= From: Andrea Righi To: Tejun Heo , David Vernet , Peter Zijlstra , Ingo Molnar , Juri Lelli , Vincent Guittot Cc: Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , linux-kernel@vger.kernel.org, bpf@vger.kernel.org Subject: [PATCH v4] sched_ext: Trigger ops.update_idle() from pick_task_idle() Date: Tue, 15 Oct 2024 13:15:39 +0200 Message-ID: <20241015111539.12136-1-andrea.righi@linux.dev> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Migadu-Flow: FLOW_OUT Content-Type: text/plain; charset="utf-8" With the consolidation of put_prev_task/set_next_task(), see commit 436f3eed5c69 ("sched: Combine the last put_prev_task() and the first set_next_task()"), we are now skipping the transition between these two functions when the previous and the next tasks are the same. As a result, ops.update_idle() is now called only once when the CPU transitions to the idle class. If the CPU stays active (e.g., through a call to scx_bpf_kick_cpu()), ops.update_idle() will not be triggered again since the task remains unchanged (rq->idle). While this behavior seems generally correct, it can cause issues in certain sched_ext scenarios. For example, a BPF scheduler might use logic like the following to keep the CPU active under specific conditions: void BPF_STRUCT_OPS(sched_update_idle, s32 cpu, bool idle) { if (!idle) return; if (condition) scx_bpf_kick_cpu(cpu, 0); } A call to scx_bpf_kick_cpu() wakes up the CPU, so in theory, ops.update_idle() should be triggered again until the condition becomes false. However, this doesn't happen, and scx_bpf_kick_cpu() doesn't produce the expected effect. In practice, this change badly impacts performance in user-space schedulers that rely on ops.update_idle() to activate user-space components. For instance, in the case of scx_rustland, performance drops significantly (e.g., gaming benchmarks fall from ~60fps to ~10fps). To address this, trigger ops.update_idle() also from pick_task_idle() when the idle task keeps running on the CPU. This restores the correct behavior of ops.update_idle() and it allows to fix the performance regression in scx_rustland. Fixes: 7c65ae81ea86 ("sched_ext: Don't call put_prev_task_scx() before pick= ing the next task") Signed-off-by: Andrea Righi --- kernel/sched/idle.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) ChangeLog v3 -> v4: - handle the core-sched case that may ignore the result of pick_task(), triggering spurious ops.update_idle() events ChangeLog v2 -> v3: - add a comment to clarify why we need to update the scx idle state in pick_task() ChangeLog v1 -> v2: - move the logic from put_prev_set_next_task() to scx_update_idle() diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c index d2f096bb274c..3e76b11237a9 100644 --- a/kernel/sched/idle.c +++ b/kernel/sched/idle.c @@ -466,6 +466,20 @@ static void set_next_task_idle(struct rq *rq, struct t= ask_struct *next, bool fir =20 struct task_struct *pick_task_idle(struct rq *rq) { + /* + * When switching from a non-idle to the idle class, .set_next_task() + * is called only once during the transition. + * + * However, the CPU may remain active for multiple rounds running the + * idle task (e.g., by calling scx_bpf_kick_cpu() from the + * ops.update_idle() callback). + * + * In such cases, we need to keep updating the scx idle state to + * properly re-trigger the ops.update_idle() callback and ensure + * correct handling of scx idle state transitions. + */ + if (rq->curr =3D=3D rq->idle) + scx_update_idle(rq, true); return rq->idle; } =20 --=20 2.47.0