From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f73.google.com (mail-wr1-f73.google.com [209.85.221.73]) (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 DC70D3CF02F for ; Tue, 5 May 2026 08:02:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.73 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777968122; cv=none; b=SpxgR5WGTJOervGcfvyqblwlW7YB00P+t16t51QacC9ebejMhzUsuJYBL/7Jckt9ne6vIxwF7Z/A1+2qcemVDrF/431kPebr6Cy1am50Xw8ZEMCwZryoR/85iaNwnKR/ZJDQHIoVQi5E0FXecwhWwjXbQkJqoGMYwVJHjqN00k0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777968122; c=relaxed/simple; bh=NxwtX9irAEFeGS8HS5VT31YpTjN+TQ3bVZMKEVe1n3A=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=YMR/7IfaIK1es8mOwNogoxB1a5K3x+HddvK8uiI0hvPsnLHtgrKv6bR9xPN+XCqKtdxYeMy395e+kGhSapC7PDJCJg0tu6PcM2BBOxaRcAUAdgpmLrJgAOlLKgKTyKMcNHP9zZz8S108lLEIzbBYoKeuA3AYsZEe0qiGFjFN+2g= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--jpiecuch.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=GFqlUFcR; arc=none smtp.client-ip=209.85.221.73 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--jpiecuch.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="GFqlUFcR" Received: by mail-wr1-f73.google.com with SMTP id ffacd0b85a97d-44bf1ac8893so2808406f8f.0 for ; Tue, 05 May 2026 01:02:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1777968119; x=1778572919; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=yKfTNSHVltU1PUFK1e+z00kOFW0Io0Jitydvnmi45+M=; b=GFqlUFcR+kaALNAgZbQnjuLq7pfvNi5+r63BdVKDLktAKqgZLGvLOnIOxJor2qqDWb OUjiWkflCw3rjPxQvhElB2TQwKW4/cPuYX2yY4OG+GAwDIAZ5XML59u5IQGpgHfFs5au QBlDkU12J8GEVm2HZ1UFD/QYPkf3dlrKZ76ziFBwRZVygkOBHy7SWAw7rFnjx6ILHq28 xo8/VkZjKwD58vT8wTBlAq0Wp8Y0r7MQjGp/H5fz9qzcRS+EYmTi9iqVUNcw1x25fUaG 9rHqcyZjJ7mqGiqBG5sfBdNzTXUfzvDRSlPyXC6YgcWgWfqqaV3LcjhJsEgaOKEUva/U QsKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777968119; x=1778572919; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=yKfTNSHVltU1PUFK1e+z00kOFW0Io0Jitydvnmi45+M=; b=s/dh2pArXlAas57hBeF5hoxS7WrKOjlKnowUmer1oT1vkwl2dpqPaMAQO3lxofYKIq 82PwA/XSsO1fbdqtUbJAAg2NEwgd1RrAuWutp+3Qv12VIhy6OhiqbAMBMdo4sImArDhe gbeAnUf7dqLmfLtIBp/w5bk9JS/AnIuxqzT5g2Xy1wALZxjso9+MwTxvqyrgihm7X6M7 5Sl5/WzHdvLRqyQNjh1iB3EnyQUrMtTkgr7Bv+ruI04bKCQtV78kMrN8e+O8GFKn4FeK W7evK5PWr3+xKLYS6Dw201eoAw7qA97tCZB8vuoFHFr7c6xVlp/qVls1ej2T4nus7CEF QSdQ== X-Forwarded-Encrypted: i=1; AFNElJ+R3GXb5RPr+1uFv+UedGeYs/r7USmuMk3Ire0+lTbUQ/PfLK61I/tbAQ42bt18/qMYT/OPYRTZdFNTsFA=@vger.kernel.org X-Gm-Message-State: AOJu0Yw+LwUDPs8dLGkjCl3jEtBkIwqTSbP616dLjAiiO2SpDZnidrE2 pIPHiJ+nBLPv/NOJHxCLHxMgkZoTpaV5b5+QPiYaWy7otr9ypGyYndrapjsXKQUN5Xf8N+P5kzZ x8jbMITCJk3I5UA== X-Received: from wrwb3.prod.google.com ([2002:a5d:6343:0:b0:44f:c72:611e]) (user=jpiecuch job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6000:4301:b0:43d:1dfe:350a with SMTP id ffacd0b85a97d-44bb66d4b36mr21738273f8f.22.1777968118914; Tue, 05 May 2026 01:01:58 -0700 (PDT) Date: Tue, 05 May 2026 08:01:58 +0000 In-Reply-To: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260422142633.G7180@cchengyang.duckdns.org> <20260426093756.Gd781@cchengyang.duckdns.org> <20260502000039.Ga94c@cchengyang.duckdns.org> X-Mailer: aerc 0.21.0-0-g5549850facc2 Message-ID: Subject: Re: [PATCH v2 sched_ext/for-7.1] sched_ext: Invalidate dispatch decisions on CPU affinity changes From: Kuba Piecuch To: Tejun Heo , Kuba Piecuch Cc: Cheng-Yang Chou , Andrea Righi , David Vernet , Changwoo Min , Emil Tsalapatis , Christian Loehle , Daniel Hodges , , , Ching-Chun Huang , Chia-Ping Tsai Content-Type: text/plain; charset="UTF-8" Hi Tejun, On Mon May 4, 2026 at 9:24 PM UTC, Tejun Heo wrote: > On Mon, May 04, 2026 at 08:00:50AM +0000, Kuba Piecuch wrote: >> Random thought: If exposing qseq values to BPF directly is undesirable, then >> perhaps a less objectionable approach would be to expose them as opaque >> cookie/token values? Same semantics, but fewer SCX internals leaking to BPF. > > Yeah, cookie sounds fine to me and let's clearly note that this is for > schedulers that don't implement properly synchronized dequeue. Could you elaborate a bit on what you mean by "properly synchronized" here? To me, introducing cookies is primarily about adding flexibility around managing the "dispatch window" between the qseq being probed and the actual dispatch attempt in finish_dispatch(). For example, a CPU can get a cookie and pass it to another CPU to perform the dispatch, which is not possible with the current interface. On another, slightly related note: I'm considering making scx_bpf_dsq_insert() and other dispatch-related kfuncs that manipulate only CPU-local state callable while holding BPF spinlocks. This is something that the comment above scx_bpf_dsq_insert() explicitly mentions: This function doesn't have any locking restrictions and may be called under BPF locks (in the future when BPF introduces more flexible locking). I'm not sure what "more flexible locking" means here, but this can be accomplished by simply adding the kfuncs to the list of kfuncs callable under spinlocks in the BPF verifier. Are you aware of any previous work on this? Any pushback from BPF folks? Thanks, Kuba