From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f180.google.com (mail-pl1-f180.google.com [209.85.214.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DCDE9255F28 for ; Thu, 28 May 2026 02:54:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.180 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779936844; cv=none; b=OsykCu8gr81EIsxrvrlwDJTC/4lGb+GpJp/8WCfouG6NjbHcxacm0jhdxbuE0HZVPVipOId0OrnYP0OjnlB2q9x03WterUiAkjPkQPRADFbeUA6sLv5/JxafTLh9Op79JbG0t56jLmeuW0MGCH/iDhCq/6FncPPoMyuRBaaLZRw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779936844; c=relaxed/simple; bh=jkIF/uI6OpWbPs+UO2A/vqAqrubs6R3F1w7AqmosRkA=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Vul7FvzibJKmRX3VUrGjWcmnBwaB4YQJxKA7sWm3q9Di68zaTfmiX+OYCB1chjo8kIFnGMl/Bd9z8ArP9VKEiz/xw2u4M12gbPT+p8x71JA+VdFvjUEHb3hs+h5cTjnivcNAE0L3RMFp+BnvcLxy+fG2Qb96+YDlJGG6IhKLXYA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=B6Pet3Ef; arc=none smtp.client-ip=209.85.214.180 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="B6Pet3Ef" Received: by mail-pl1-f180.google.com with SMTP id d9443c01a7336-2bc763e2ba8so62735695ad.3 for ; Wed, 27 May 2026 19:54:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779936842; x=1780541642; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to:subject :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=8rOvmruqBOQaVQQy1Yls1qWAcHtuLmD+8Nz7yrmG8Pg=; b=B6Pet3EfZNqfhjACHJ3YpwG7Y0A5o4o8S5CGAYKplDdE0hXjVj+qOV2M+cR0pd0/zQ CLSbHGGrY9uwtudRqowlP46N0AQThWmBOek77FKMQ/NTPTWPB/UiDcZec14LsPbN16ua DigrYjaxInJVGHNXFWpKzJjLPBETPs7NRKiGVKcPjhC7pRgM5VFwJsZwyoOpz53eb8nX eCzinqdal4G511/wJSYl+pG0NWkBVAlt2eAzQDz2K/7bMfcvqsUhKc+AKce8dGL3H+yR MyipTgSu5zsPhsLL2UHeJsSPwVcU+t7fNZIkfY6ZnrSA6ZKa6U2+LHIBjB/bnAdITDVy SxIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779936842; x=1780541642; h=content-transfer-encoding:in-reply-to:from:references:cc:to:subject :user-agent:mime-version:date:message-id:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=8rOvmruqBOQaVQQy1Yls1qWAcHtuLmD+8Nz7yrmG8Pg=; b=rHnl3LakAGm9M3GMDC+o7Cg+2vST/rnIHYPaVzIN2WRJaRsiQXxJ6nYoz08ZdWTkxk eggz+B5QNyvilBhkZRNH859bBSzCyO+wBRUh8vBD9xzkz2IstZwm85viZ3txqyUGpnww iPll9WQLyddHsWKe9/hD/dSm9qNGsT2VspiY2o6zwMP3cX01ezH5q1ACXSnaDcU6N72s Udku09idtFZ1LBcKlov2zrrNbW3kpYyUlTbTHj9DeWQEgkHpE2VRNztsCu9Kl1u4XWXK I9ljfCQGhanxxk2TWCUG2LKeZ0BnLWgOwMyjM+Xh+Rt1Q2FXPYjAOMsM6dimjb0nyHQ2 uyMA== X-Forwarded-Encrypted: i=1; AFNElJ/bZRImVDGH+IDRjYBiBIFQ3CwZvqUOhOZVcOsE/VJl7372PnsdRrhJDGX0F0M65pmTRn6mdqkUUWeuv4I=@vger.kernel.org X-Gm-Message-State: AOJu0Yy5VqmGEBV9+q7xTqcLiH6w+MXZoN9JqDY0kOxkPzNHNdDpiLfI 53jit545RNC6FWi2xh0U9Hh/Bw/QIEccpZ11Jt7VoYjwrRvPA9eDGzwW X-Gm-Gg: Acq92OHJSU66P+J/NFTw1UmxB4ikQivfdrmfykECdUjXIhHOimmHB3erV0t0XAXLql7 EfS2l736iQuWP0NXMJjf+B/ia2gWIiPVg0owQ8NIMBc4MdMBgq5dTKdwCk9KwmL605p0znTcmvu Ioe2FWpQp41pd5i4lqlnqGtuFOpLqeEfvOQ/SYBzuYDC3/rAaUUDMvYdmp+jv5Psfmiju5u9ewq XTtq+BbdSsoPWGDjguMQ4whevu6hDdcWhZMtjKyinudlzmrbw/iuyd7MibGfmR0BO07YPSy5xMX S029XwFzh7j/5f1b+6nsfkyIoA3pzMH1d3TDTnk7x0WNKwYLSnK1jGxsqSuuRnl775LPpIihzuU wtq63G8hSN0A3GcMqnCIg5onRayMWhJ06vtEIj7o5pTnOi0zzHODpqV8FAWymVe6BzV9QuKcg9t zoyGoTSqd7aJl/WQbBi7mQaJsxZRCjFX/7FDz06WDhjGC/IqzNOLHolMA= X-Received: by 2002:a17:903:1245:b0:2bd:8c9a:a684 with SMTP id d9443c01a7336-2beb069c63cmr287081535ad.4.1779936842216; Wed, 27 May 2026 19:54:02 -0700 (PDT) Received: from [10.23.182.65] ([139.159.170.72]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2beb58b3058sm171402855ad.39.2026.05.27.19.53.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 27 May 2026 19:54:01 -0700 (PDT) Message-ID: <3c258a36-2b28-4221-b2b6-776a0b1693ab@gmail.com> Date: Thu, 28 May 2026 10:53:54 +0800 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 v2] sched_ext: Rebuild fair weight on ext to fair switches To: Peter Zijlstra Cc: arighi@nvidia.com, brho@google.com, bsegall@google.com, changwoo@igalia.com, dietmar.eggemann@arm.com, haoluo@google.com, joshdon@google.com, juri.lelli@redhat.co, kprateek.nayak@amd.com, linux-kernel@vger.kernel.org, mgorman@suse.de, mingo@redhat.com, quzicheng@huawei.com, rostedt@goodmis.org, sched-ext@lists.linux.dev, tanghui20@huawei.com, tj@kernel.org, vincent.guittot@linaro.org, void@manifault.com, vschneid@redhat.com, zhangqiao22@huawei.com, quzicheng315@gmail.com References: <20260527094037.3494671-1-quzicheng315@gmail.com> <20260527112624.GT3126523@noisy.programming.kicks-ass.net> From: Zicheng Qu In-Reply-To: <20260527112624.GT3126523@noisy.programming.kicks-ass.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On Wed, May 27, 2026 at 07:26PM +0800, Peter Zijlstra wrote: > This is truly horrible. We have 4 class methods involved with switching > classes and you stick in a random call in a place that is called when no > class is changed. > > Would not something like this work? > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > index 62a2dcb0d03e..a2eb43bd73b9 100644 > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -14957,6 +14957,11 @@ static void switched_from_fair(struct rq *rq, struct task_struct *p) > detach_task_cfs_rq(p); > } > > +static void switching_to_fair(struct rq *rq, struct task_struct *p) > +{ > + set_load_weight(p, false); > +} > + > static void switched_to_fair(struct rq *rq, struct task_struct *p) > { > WARN_ON_ONCE(p->se.sched_delayed); > @@ -15351,6 +15356,7 @@ DEFINE_SCHED_CLASS(fair) = { > .prio_changed = prio_changed_fair, > .switching_from = switching_from_fair, > .switched_from = switched_from_fair, > + .switching_to = switching_to_fair, > .switched_to = switched_to_fair, > > .get_rr_interval = get_rr_interval_fair, Yes, from the class switch point of view, `switching_to_fair()` is a better fit. Before v2, I was weighing three possible places for the fix: 1. Updating `p->se.load` from `reweight_task_scx()`. This would keep the fair weight in sync while the task is on sched_ext, so switching back to fair would not need any extra fixup. However, it would also make sched_ext maintain fair class state even when fair is not using it, which does not seem like the right ownership model. 2. Rebuilding `p->se.load` from fair's `switching_to` hook. This is the most natural place semantically, since the task is entering fair and fair prepares its own state before enqueue. My only concern was that, for non-ext -> fair paths, `__setscheduler_params()` may have already updated `p->se.load` through `set_load_weight(p, true)`, so calling `set_load_weight(p, false)` unconditionally here can be redundant logically. Functionally, though, it is harmless. 3. Rebuilding in `sched_change_end()` based on the old/new classes. That was the v2 choice because both classes are available there, the task has not been enqueued yet, and it covers both `scx_root_disable()` and the partial-mode `sched_setscheduler()` path. In hindsight, though, this makes the generic sched_change path handle a scx & fair-specific fixup. That is more awkward than letting fair prepare its own state in `switching_to_fair()`. I'll respin v3 as you suggested. Thanks, Zicheng