From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f48.google.com (mail-pj1-f48.google.com [209.85.216.48]) (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 E6420392C44 for ; Fri, 6 Mar 2026 12:49:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772801353; cv=none; b=CSRmv++6ei5uH9iU6oXrRJ/RNvrbglqtVc8FPNd0N7mS4c3zGaDRDhgUCdiWi9KbmfqOZpOS38rpDInxtHJsxbaWk6AyP1q6LHuI1lqCkJ2gtFOHakz3zgiX1kVTJ34VFgX5eVTrOaFJ+ofdcWlSKjYlQ8u8Me2MQlESd0DSO48= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772801353; c=relaxed/simple; bh=0OeY0xReBFL8eCyB/FrdWjGk3Mhp+R/qkHPO1eyeEZ0=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=roxV0bGkZLNRfy4jY3HeQ8325v9kWHGnhtCYz7LWtK7NuMfK2+LNwJ8m/asJuoGuDBCuglVPPbOs90mx0A62ufmhXYu3hOCThxjnAALaFq1pINWTZRUDo5JjOBvz2zufwYP5zNwKOimfbby0Bu1JJnLUhwwA2Cmn0SuTfT9KddE= 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=DtGMHuNF; arc=none smtp.client-ip=209.85.216.48 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="DtGMHuNF" Received: by mail-pj1-f48.google.com with SMTP id 98e67ed59e1d1-354a18c48b5so7977243a91.1 for ; Fri, 06 Mar 2026 04:49:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772801351; x=1773406151; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=usOL8l/KNsMfxD0BXV4D931Ky3sdKsa4TTa5Fbius5w=; b=DtGMHuNFwvjoI/7+psX/YiF65l6F3AeEtusUqqz+whu7UcODWPC9X5gRH9YP8caihO CkgZ1+tT2BOnZX7Do9Myod5yTtSueYBt45v/5aiEsu8f8sAUX6XS9fJdoYAKipwspPMg gggi9LGszSDqGFoE9/bXzmyRwnoBtILPToZCXeo0rWKH/lOymloBq8WsazDLya8E1jRk bC9lJeX8U6KVzgxWvPf32AWV9GyjJLhGMIPrXPV2MjgX7PxfbJdmG7nhtzyd5G9ayWN4 L8skd7QXOenghIlOQowLA/GUs/iS3KgPEqZt6zLwJrakkBPvnpsrXrpJhH4z+tk2F8Bn SEUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772801351; x=1773406151; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=usOL8l/KNsMfxD0BXV4D931Ky3sdKsa4TTa5Fbius5w=; b=ZMtRMVTx5HyQPuLMlnuFSLBpfIlt1dB5gWzPYLgdeslzcFklcuqwm0MjHMKwfEQwb6 fHUIFRcTpJtY3VgnYxRjo5vPyWGvRVi4kYq6VK4cUIc1dLAsKNxYfuZtJfVL2LKo/Vkl ITS1EYLlYrYHk1WVbA7hfv0dbM4BGkLHHzEgnFcM9TSXST3LHOd1NM0CVGepBJLGib7O 9j3P4HwtP4mWu+ig4614yq91z2DCN4R7A6MjbRt0KtlsJL8MqcHgVEySieBoQ7SB0p3f BSRX6NKS6yQoGs+86SAphvca2Iq+vOaydQ3SRRnBMvak7i2sIopFCyY6eQ7gzlJnbSER q/gw== X-Forwarded-Encrypted: i=1; AJvYcCVUALIIcab7NOOCXNwhu52fWSV2btDwrTTOXGS30jhY314YJwO1jWyaeXZEkEru2xJBnXb9+4fEvnq5czM=@vger.kernel.org X-Gm-Message-State: AOJu0YzOvWlnhPO4Cu2PfaqX4Q3pxkluymeCktfHP4Enp0xPXPqmbYCG AmnlZ5iI0ivxswOdus2ScYcoPDgRoE8TO7lUn1zjMX8TvziZOP9qIHIV X-Gm-Gg: ATEYQzyH/Lfqust/lrJZoccvkW1WEN9hqtJ2l9ExwCW9yxiNM1RhCsO5Oq/Bo3Qb1Lp lvqYt9pWx5q6LqdAylTosVcLmnXyaaq42+EZp9uBGNyd+IDE3xJDcpB1fWzS/2FghT4dJFnKfI1 vnB6y2eaoaJ6rxetK77lwwpGRYq74JPX52grlFL5416hyY2shQB6ttV9Ooo/olAhiwHNOnywhCC Si9doxiL6H2qJCgqyjrJND2etw6sIVj8tmajK5lK1MpUKd7pHWOGHo4ffezfJi06gUfBAfC9APz s6KzIbYV7pgVT4Bs6fpZTE1PKeWWrhNcMiOexmq0p+W6XsdNQIkL9RsFT4RmKBVd5gFNDQ/dcSr HOmuA7pFz0i4OQH/uplG+gnIDMZ8zvG/SIUaEjrtU+viMgv5VTGhi+o7K0ta7eMnGAG6iOmH5bu 01ySRtSRU5bobPRfi3jmJBcIFgyimDAV97g9LdYaMOs8EyLiDuFWs+OMjm/HXTUJtgaTpwWiKUT TE= X-Received: by 2002:a17:903:faf:b0:2ae:7f7e:93a8 with SMTP id d9443c01a7336-2ae8248ab08mr22623655ad.51.1772801351191; Fri, 06 Mar 2026 04:49:11 -0800 (PST) Received: from mi-HP-ProDesk-680-G6-PCI-Microtower-PC.mioffice.cn ([43.224.245.226]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2ae83e78f77sm27712845ad.21.2026.03.06.04.49.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 06 Mar 2026 04:49:10 -0800 (PST) From: zhidao su X-Google-Original-From: zhidao su To: tj@kernel.org, sched-ext@lists.linux.dev, linux-kernel@vger.kernel.org Cc: void@manifault.com, arighi@nvidia.com, changwoo@igalia.com, linux-kselftest@vger.kernel.org, Su Zhidao Subject: [PATCH 2/5] sched_ext: Add comments to scx_bypass() for bypass depth semantics Date: Fri, 6 Mar 2026 20:48:58 +0800 Message-ID: <20260306124901.2653465-2-suzhidao@xiaomi.com> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Su Zhidao The bypass depth counter (scx_bypass_depth) uses WRITE_ONCE/READ_ONCE to communicate that it can be observed locklessly from IRQ context, even though modifications are serialized by bypass_lock. The existing code did not explain this pattern or the re-queue loop's role in propagating the bypass state change to all CPUs. Add inline comments to clarify: - Why bypass_depth uses WRITE_ONCE/READ_ONCE despite lock protection - How the dequeue/enqueue cycle propagates bypass state to all per-CPU queues Signed-off-by: Su Zhidao --- kernel/sched/ext.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/kernel/sched/ext.c b/kernel/sched/ext.c index 56ff5874af94..053d99c58802 100644 --- a/kernel/sched/ext.c +++ b/kernel/sched/ext.c @@ -4229,6 +4229,14 @@ static void scx_bypass(bool bypass) if (bypass) { u32 intv_us; + /* + * Increment bypass depth. Only the first caller (depth 0->1) + * needs to set up the bypass state; subsequent callers just + * increment the counter and return. The depth counter is + * protected by bypass_lock but READ_ONCE/WRITE_ONCE are used + * to communicate that the value can be observed locklessly + * (e.g., from scx_bypass_lb_timerfn() in softirq context). + */ WRITE_ONCE(scx_bypass_depth, scx_bypass_depth + 1); WARN_ON_ONCE(scx_bypass_depth <= 0); if (scx_bypass_depth != 1) @@ -4263,6 +4271,10 @@ static void scx_bypass(bool bypass) * * This function can't trust the scheduler and thus can't use * cpus_read_lock(). Walk all possible CPUs instead of online. + * + * The dequeue/enqueue cycle forces tasks through the updated code + * paths: in bypass mode, do_enqueue_task() routes to the per-CPU + * bypass DSQ instead of calling ops.enqueue(). */ for_each_possible_cpu(cpu) { struct rq *rq = cpu_rq(cpu); -- 2.43.0