From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f180.google.com (mail-pg1-f180.google.com [209.85.215.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 B716948AE1B for ; Tue, 5 May 2026 15:58:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.180 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777996700; cv=none; b=Kn0wGUhcaeAvhYxQ/H+I/5yfZL9YnBxoYoqS2/NooTy/9sZzP+lwAK4f6aca32sxuRR6t94OSLnurSeZLsH2KIiJOrUzsHZNuebd72Qu31eigx6oagiwyeqykxeDsCu8YzKBX5gc/2yyufq/mq4LhlD+SiLt52TUBgLl8Uii/Do= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777996700; c=relaxed/simple; bh=q5u/UdHFSJSvCX3OoYzCme3wenzpAuPuauy9KaBJs0o=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Oe8w3s5SXcD2DexKRlzhe+hgSbNTkiZVzc45GjzJEQD0R5UP0ZlOl8xA3+gtztvUGmbgAGnOWp5xWbRJ8HqNQ37C4FlwuOy4YkqIajQ5GbDZ/LSwAH8gOj/DwJmzQK+zG9v+THMNKanzdcLe0f76iN4dWIcU8xd1oNwVv8aXR0E= 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=deEGiJ+g; arc=none smtp.client-ip=209.85.215.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="deEGiJ+g" Received: by mail-pg1-f180.google.com with SMTP id 41be03b00d2f7-c801b30188dso1174208a12.3 for ; Tue, 05 May 2026 08:58:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1777996699; x=1778601499; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=GFNz8igJVfgZfXbWHEAoaJ0onW3oZl+AuVGbjieeRbM=; b=deEGiJ+gIp6WNC0I5uiUsRgexmo8puOkj7LzYpuVhV3FJtvjcDo0tGYOyHsXVcBKLQ lTQwqLPQrVpa27MhoxY/MAFTwnQIBcNsfUuVuaMBRQ+5S37qtzPnBBJLF7teazoOU6t8 ide/T6IVLgEfTk2WlUXBawdcJISwmoNInYpuJpIf8goLdVNhwZSGuTUZ+3pWs9LoBVs4 ArfJCptct0GYxclnbtn9Xm26i3FSWCP0vwCfUGmllY5cofSj0DeZo8HDP0rcTYZ+Nq+A 4gSzSuPi9OYh1u+7dXImUVyRscZIFQiTCagxFfWWNBrHnNIrPJGeKQnK8pyyU+6H+BZd HvQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777996699; x=1778601499; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=GFNz8igJVfgZfXbWHEAoaJ0onW3oZl+AuVGbjieeRbM=; b=i+fbEHuoBqcfQXK/mbMnDeVfkuG78gE0+KCywJrED31tTZWuF6jpwkmAvXfeXGu32s Lunu+XbPTrVfBL00HZTikoX9JBnSC/YGcTkY+mJSso4x+s8VoxC5dc0YqKAiuxLLFavw zMpxtf8VEZrXrqmjiWKmx4VUBiznwzv6MwLnpBYbI8i3kvgsExc2Ph0RPdX5NjG2EiCo GF58ay6+PJTt6eobZg8O5T8Sdkppq/Qc2xPQZGaunVC+0cCE9B3J+NJ/0AM8mxQNjfOG ZwEEzqid4zZ4MVFHRATBnQm2fiQku3gzZJEmrw9g8MeYAaI+82NdKH+4SuUKPH/uLYR2 8oeQ== X-Forwarded-Encrypted: i=1; AFNElJ+7KI9MCmewScbKcTyiwlxPvY1kSTkHSzLl99MUg/od7khnIqfmaLuysI+hsSehr3gjDXruBU/2LxOAGDc=@vger.kernel.org X-Gm-Message-State: AOJu0Yz/toQjXbGmqhemuDfvpuEFbzufREVlEd/N4XWgV24g5grhDXyW +ozvH9slj9rfNdQIUlWsROrhzfyXcx6zsOUBiwrWjEwMdb0wdJ47HP6E X-Gm-Gg: AeBDietBllTcl+X4FvopLAavtm7N9gMwqXv8+YwLc4O77heZqnMEo1ikK0DWFH+P7/7 qUQT/RqVAtoSKfSF3eO7KNCWA0pByAwfibM3hIdUcLYuxIlZrZ/ft75C1yCCbjz9tBQZUGMKRve YY0iMOdzZZTaOhXT4F/R0N2oZJ3QZgKgnZVJffIrtFMqESNVHwUAPi31shHxQ+iHHge5F+P4afp 39bgNjfFZ8LgE6tP7IP84hIGAHz4e2Fnz8TnT8w0lU70SQlHzoU/uyVXA/hPM0WqMYOiXWx7NL4 +eglqlX84A+JFdfk84ivnaN54CiVCMpFXspfF+qZuWgakrmzTDpZwV/aw7brjTZRdGIm6RkYtG/ fPHpTroPvrqoXjtNTm+SXNqDga8eeINhVkXio4N16XfzLf0tdZ+ByQd+bsmCnnTzVuj7fpkN008 IEihncCJSlwbQ8dSyEcW+jr6RxeBa43/2y2lA94XZNxX4mE4x1U+lhkbjB3kVSnonjx9hDtkF21 cfAISakxujsULX+V5EQ7aZF6DE= X-Received: by 2002:a05:6300:210e:b0:3a2:7ef4:81e1 with SMTP id adf61e73a8af0-3aa3b87f72amr4177149637.47.1777996698921; Tue, 05 May 2026 08:58:18 -0700 (PDT) Received: from cchengyang.duckdns.org (36-225-109-31.dynamic-ip.hinet.net. [36.225.109.31]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-c7ffbc6f84asm12360504a12.19.2026.05.05.08.58.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 May 2026 08:58:18 -0700 (PDT) Date: Tue, 5 May 2026 23:58:14 +0800 From: Cheng-Yang Chou To: Tejun Heo Cc: Kuba Piecuch , Andrea Righi , David Vernet , Changwoo Min , Emil Tsalapatis , Christian Loehle , Daniel Hodges , sched-ext@lists.linux.dev, linux-kernel@vger.kernel.org, Ching-Chun Huang , Chia-Ping Tsai Subject: Re: [PATCH v2 sched_ext/for-7.1] sched_ext: Invalidate dispatch decisions on CPU affinity changes Message-ID: <20260505234158.G1d71@cchengyang.duckdns.org> References: <20260422142633.G7180@cchengyang.duckdns.org> <20260426093756.Gd781@cchengyang.duckdns.org> <20260502000039.Ga94c@cchengyang.duckdns.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Hi Tejun, Kuba, Andrea, On Mon, May 04, 2026 at 10:31:28PM -1000, Tejun Heo 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. > > > 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. > > So, this is mostly for schedulers that don't want to or for some reason > can't implement proper synchronization between dequeue and dispatch paths. A > convenient thing to make life a bit easier. I think we are on the same page! I'd like to take ownership of the cookie implementation. Andrea, as we discussed offline, please feel free to send the deferred SCX bandwidth implementation, since you're already working on that. I want to focus on the cookie implementation first, since the design has been discussed for a while and I want to move it forward. Here's the API I'm planning to propose: - u64 scx_bpf_task_get_cookie(struct task_struct *p) Returns an opaque cookie representing @p's current qseq. The caller can store this in a BPF map and pass it to another CPU. - bool scx_bpf_dsq_insert_with_cookie(struct task_struct *p, u64 dsq_id, u64 enq_flags, u64 cookie) Like scx_bpf_dsq_insert() with slice=0, but uses @cookie's qseq instead of re-reading ops_state at insert time. A stale cookie causes finish_dispatch() to silently discard the dispatch, which is safe. Will send a follow-up patch soon, thanks! -- Cheers, Cheng-Yang