From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f74.google.com (mail-wr1-f74.google.com [209.85.221.74]) (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 4A700239E9A for ; Tue, 5 May 2026 09:14:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.74 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777972441; cv=none; b=enZxKDYkc8zNDQqmJagz4dS25ySQ6QG2FaFGq05I3P6Mfu9veQd/hvnkFCWLoy7FF7b8rYjyMxjklwJoBloMCC1zjzlWhPZgDc1Z1XDDAFEWqd87ReB4K3xI04KRPukLfIB4kwiwappz6MWEO2gzfhpERto3XLMyjQyF3Ua73NE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777972441; c=relaxed/simple; bh=ozZTD3AagtSW8An+sSwE03SzOTDlXwzRcRkGC1PNPmw=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=dS8y27HPEUfN8e9rugHWPxYnUNqbClE1zlh5PzeDfNoCskhI+l1BkzPrbVLn2uGhkt2s+WVskG1isWWjIzNeU/hqgFjsr1HM7i//+gikSsPCHIQsqEK2ydNhR0JSXZ2Ivw/fVMGA3fT6kx3/ACj7K56214A87mZX5cMxIGVbDJA= 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=VhZSBPY0; arc=none smtp.client-ip=209.85.221.74 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="VhZSBPY0" Received: by mail-wr1-f74.google.com with SMTP id ffacd0b85a97d-43efc93e4f6so3815199f8f.3 for ; Tue, 05 May 2026 02:14:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1777972439; x=1778577239; 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=CfOXjO28QWIi6sr7QzygIUlzNqE9gXOJzKbu5PdV2ZA=; b=VhZSBPY0NU5BgHiE6YFDtPjqQRvlO6N1NgOoBnC2Fjc/JtLG0DqGVdAmzARuUfzDLb 2W/EIAr1CgXK6ehwM1o/afzjvCQkTaKP3lVdhS0h7BsuxaNB3w+odegeGNs0HrIHCsY9 SIzl69pPyIKSvofCQP4Sjays66VxxvpkZ48rQ4MX9SNBImHa6lNI/cEt+tYaE3QzbJbP ooMpwBp3UzjLsJY59kpzdeoCR9YknKUaDIPspymdJGCR8VkEEsPXmT/dIRLeKS9c0PN0 QK9YQkPQU6cVikYLb+twdynCQ1Jl0m/BB2rcMhlzlaeeajVxBORF7l7dTzr33CgVU3ff 9g1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777972439; x=1778577239; 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=CfOXjO28QWIi6sr7QzygIUlzNqE9gXOJzKbu5PdV2ZA=; b=h9zsktgNod9YLjdij8LreYbEPEuVdevl3RbOEzP0YeLjh2cWaFWqDWzfAY/eWQjc8f M5xGyfPtn3QIbMkqmtPNvdc5wkyLyqgc9HGWiZNFSi9aapsjxy3pacKYvmTdqvSJ5mJs XHSN6tWtXfumsjKvnit+tSXXUwDtXWKRs+CMFbHinXDm84WXbx9FFZaeVo/+PWjFGdWV AZ8EHErMO1bcUDfWfuEdj/21nnPQU72lt0wdf5Oyg4FzoZlPUbwAxPHXTV8b0m8lVdTs XlQaS3cHUToEB1O/93xLoXh7DQ42eNPuLndqU5ZnQAU3Ui2QHEF7kuADQhiYCpqUn4XS ADAA== X-Forwarded-Encrypted: i=1; AFNElJ+TQjZ9yLgVMm88aaqXHqUJRil3UsjUROc6hRP3rpi93BDtQPzPKLn4Y3Jwb/3/eD0ARQnY3o554jxKuNU=@vger.kernel.org X-Gm-Message-State: AOJu0YxVCGLFDgodn900/1wWIA3Cu54ycv7jNIOQWVeYa7jisCYSR9Vg t/uHfNGAuzQUnSdQJxhWxSA2PHOFB8+JqxVGQjsdKToHnPEawHIjpopjl8P+NFNtvus+YfYEknH B7dpfSdkctOpDOQ== X-Received: from wrru2.prod.google.com ([2002:a5d:4342:0:b0:44f:298e:92c4]) (user=jpiecuch job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6000:2c09:b0:44a:fe14:3738 with SMTP id ffacd0b85a97d-44bb32fd771mr20846119f8f.10.1777972438478; Tue, 05 May 2026 02:13:58 -0700 (PDT) Date: Tue, 05 May 2026 09:13:57 +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" On Tue May 5, 2026 at 8:31 AM UTC, Tejun Heo wrote: > Hello, Kuba. > > On Tue, May 05, 2026 at 08:01:58AM +0000, Kuba Piecuch wrote: >> Could you elaborate a bit on what you mean by "properly synchronized" here? > > If ops.dequeue() synchronizes with the dispatch path so that the task being > dequeued is either dequeued or dispatched, there's nothing else to protect. > If ops.dequeue() wins, the task won't be dispatched. If ops.dequeue() loses, > the task should already be in either the dispatch buffer or local DSQ and > the kernel dequeue code will shoot them down. In the former case, at the > dispatch buffer flush time, the task would either be already dequeued or > re-enqueued with a different qseq and ignored. In the latter, > dispatch_dequeue() would remove it from the local DSQ. I see, makes sense. Thanks! >> 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? > > That comment was written before bpf_spinlock was introduced. Please feel > free to allow thoes functions under bpf spinlocks. BTW, there's also arena > spinlock that is implemented in BPF proper, which is already used by > multiple schedulers and likely to be the default option in the future: > > https://github.com/sched-ext/scx/blob/main/scheds/include/bpf_arena_spin_lock.h Ah, interesting, I didn't know there's a pure-BPF implementation of spinlocks! I haven't really had the chance to play around with arenas yet, looks like I'm missing out ;-) Thanks, Kuba