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 A3DEF374169 for ; Wed, 25 Mar 2026 07:39:26 +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=1774424369; cv=none; b=t6xPSZM7setpGMpRoCx11NLwaKPWxnxaRSGrQ4eGTV+cdeb1FJkYDkfCc4C905ikmEFl+ScMi1A7YVJPAcWfr1Z4yhoYLsa7TDPBLA1MWGw0GqaC0ZV8sQXkpPqn7Ql9wavSo1ha0nrLQBZAnFnlSHILUTFYtSEcSl3WRFYvjtQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774424369; c=relaxed/simple; bh=lKZMysV6E0Sacu7KzOg8djmM5FEzj+xPf0Kt8gq4Utc=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=rap7W2W+a+nUXgnipHuphUc0N8OwZaB0n5l3id8WGeNhle9ZJnF7mWy5msGZl1aphyo9I5Y00iCjgqpM8hIO1QcEArjfHi+eFHdW6jT837OAxcJo1d1vu3hZqxdOV0ih0b3zVM0PQQCJ4VNuyfP1qs4BmUawNiQ0Ebx/lzwmd5E= 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=StGqagRG; 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="StGqagRG" Received: by mail-pl1-f180.google.com with SMTP id d9443c01a7336-2b06c43e6a7so25158175ad.2 for ; Wed, 25 Mar 2026 00:39:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1774424366; x=1775029166; 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=1gzTsrnfq3feyER8+ccqcmHdRTIBuzq8j4Hy1T3yuBc=; b=StGqagRGy9G83y4xHFyKPA62W5ycP9ATTGHiJ8+yVUElx1kskWDEwXqjpq9YdOriXW ALPpqvrqEv50c3HeafQPh8TUAXnzYdPyXHKL9ZuqgINmSIPQBSrjBbU/Ng68ystoN15u VUa6pWkw84ZSfU3RA8N/m/sGkSpBElNfbqqhb+2LrGB6D6WH4Fa+JqDmgtDx40D0f5eR 2IG7bu1eq07YK3iyijhObBo0dyhyoSLJjcZvdmcmtcFh3WU6j1S6Vz31Oq62/Ut6P3VI lvL0LLcU1aRg2zBd22H0rutOas5Ud7XMNaeQQqSjDpNtL2/uBfB0hXNeXUb2ZWdaU6YA LfkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774424366; x=1775029166; 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=1gzTsrnfq3feyER8+ccqcmHdRTIBuzq8j4Hy1T3yuBc=; b=CoySuAUoyDenvFuTSkV2usbFL1buDI6S7TBKHOHkKYkTCLrd0VWWEghRyQCqMDvkn8 wuCqgryIk806zIiXishwh4nUZAtayV9iic2rLDHDLlldCA2aFDx5Og2zTw4q6AioluL6 bJaTlvM1dL+g4mECkqseYdFH7AQ7fk22zxQSU4IYfBodQ6aq/ePNGOSSfJc+LPdUPKs8 gSpXgc7cxKKoI8PDZ679DmC2Js35oau3PCPVae+j1++GZZ+cmKSUS6F5wVUyJHQ2sfcU t/C0pMI+6pIqIKsUKGB4msHCnnRDJHuUrCpQWLHfuv7fYNh/nKNxDXXji+txO+wFlf01 ASOg== X-Gm-Message-State: AOJu0Yy+JuYtcz4FnJlQq8/FjCtuwDQON4wh8+BOwbUF7oa01Gc0nYpI zxVR+N22Y6DBLxv048WQKOWQrD2CKqYsZ4byB3HHxPhV7Xze+t27GJRkkubKbQ== X-Gm-Gg: ATEYQzydMR3viMnfyrncfpO8xd2ARqjNxgcVAzd3mZjMnKdMYPZA4pkFK/XP1e+ZK+h xR/CJZ6RTH4eH5oZVhXE7LF7fbEb8d60KtyfiisJXoJkmuF2xWcD99iR70GP0d/HZeuMOa04HnK twv6uwD5poJtmdaHmhTcYEsaSbt4U9A8LgDY34LFy5nyod4CyPWIFvBzlMwiycGHRzqnHta49te gaM3/1tWNdTFFPZBxVLWIPhbVCgcw6fdTDOVwjcLwYhdA8MClyXUz4fI8nDNsvGXox76d0p/+wU DkA3T7aBCCrCLQa+FovBGP5DX0TdnKTDk2Z+kNlPGUIxg9rhDHtd59ztYqq65cXiHfjrxh34LIz DAPKDdTk7dBPsxO+Wvi+gnX0HBHUBefRaJHPqu3S6JFJ3X/ZOBuZ7UNc20f7SCIw+Dhxzdgjvh7 G1jypbRfhlwT8D3ICHIsqZlwq5Ra9MYqHhEoDnSc39psF7vmDZ6YRyLWZsnyBqJhA2XZ6mIZfZa EPDbBsrttcuyA== X-Received: by 2002:a17:903:3c4e:b0:2aa:e3c7:6048 with SMTP id d9443c01a7336-2b0b0a42d45mr30125415ad.23.1774424365623; Wed, 25 Mar 2026 00:39:25 -0700 (PDT) Received: from mi-HP-ProDesk-680-G6-PCI-Microtower-PC.mioffice.cn ([43.224.245.226]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2b0b0129905sm22003445ad.27.2026.03.25.00.39.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 25 Mar 2026 00:39:25 -0700 (PDT) From: zhidao su X-Google-Original-From: zhidao su To: sched-ext@lists.linux.dev Cc: linux-kernel@vger.kernel.org, tj@kernel.org, arighi@nvidia.com Subject: [DISCUSSION] SCX_OPS_ALWAYS_ENQ_IMMED semantics clarification Date: Wed, 25 Mar 2026 15:39:20 +0800 Message-ID: <20260325073920.758426-1-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 Hi Tejun and all, I'm working on understanding the sched_ext enqueue flow and noticed a potential documentation gap regarding SCX_OPS_ALWAYS_ENQ_IMMED that I'd like to clarify. **Background:** The flag comment in ext_internal.h L186-188 states: "If set, %SCX_ENQ_IMMED is assumed to be set on all local DSQ enqueues." However, reviewing the implementation: - The SCX_ENQ_IMMED injection happens only in scx_vet_enq_flags() L7812, which is called exclusively from BPF kfunc paths (scx_bpf_dsq_insert/scx_bpf_dsq_move_to_local). - Kernel-side enqueues via do_enqueue_task() that take the `goto local` path (L1883-1893) bypass scx_vet_enq_flags() entirely. This means exiting and migration-disabled tasks using the kernel-side goto local path don't get SCX_ENQ_IMMED injected, and consequently don't get SCX_TASK_IMMED set in dsq_inc_nr(). The code comment at L1859-1862 acknowledges this: "exiting and migration-disabled tasks that skip ops.enqueue() below will lose IMMED protection unless SCX_OPS_ENQ_EXITING / SCX_OPS_ENQ_MIGRATION_DISABLED are set." **Questions:** 1. Is this behavior intentional? Should "all local DSQ enqueues" in the flag documentation be understood as "all BPF-path local DSQ enqueues"? 2. Should the flag documentation be updated to clarify this exception? 3. Or is the current behavior a gap that should be fixed by applying ALWAYS_ENQ_IMMED semantics uniformly to kernel-side goto local paths as well? This would help clarify whether schedulers setting this flag can assume truly all local enqueues get IMMED protection, or only those through the BPF interface. Thanks, zhidao su