From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D20E5330D32 for ; Sat, 28 Feb 2026 17:28:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772299681; cv=none; b=N+EIr3EcenyQJ513gMrutWefVAXHBHgrhwhw/I1KhfL31E68NlZ8lDwn75MOKuMXWR3LRY9MJ/KZ7w1zobuHApKSH9b/6aN90mXhmTffIY9yMuvRUz9MbImHA/bdJBZ8WhJtnrD8u+Yb9uyVjCqVWXflLenQ+HDq8nzaR2jGAcA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772299681; c=relaxed/simple; bh=K6xbZjBI6pzp7teDlwr1Zq7uvd7C5zJcVr/67IFgzcA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=N8nso/n1ehtTQl5H1WYu5F3fSogPH850N4s+nA4Q7Ib0P55DuBoczKSorhdGigA4ldHza1jsBAepI8EEm+iopo4NtIWdlRY53K9NxSpx6wcL0fz7oCwIXdmnd88eiXsYywlAppa7rTM0U+xLfTVAv6DZcP3jIqLwZG9l+1U17cA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=gz//GZ6E; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="gz//GZ6E" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 93686C116D0; Sat, 28 Feb 2026 17:28:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772299681; bh=K6xbZjBI6pzp7teDlwr1Zq7uvd7C5zJcVr/67IFgzcA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=gz//GZ6EqmkS2VSj+1wR63Nr3rbbzLA1pB3ExoYcIyH2oD94bZn2BHSd/Z6n/ke8+ KkxUujM1t9+FB0v+FtRrrzWI41U06pHX6W00s5PbKJpJlvjHon9RDICMFcPUD8KZsu mauwrXrclIhObKdgAoQlTiBJjS7BmT5npkcKO96EHfJnHAqmZivrOwlruP3bCNLgUZ O8vH6ClMCh1x5AUdxb6ku25CFYc9dMYBdqfyJowmgaQoWYUTNqbmJwq96J20IntA4C 5Y2T1xgN61S+Iaz02b3FAjROtaHx4K9Abb+8Eyjj4tBFvbPLc0TfAQ7ST+XvF6KMe6 lQj2zdVz32G2w== Date: Sat, 28 Feb 2026 07:28:00 -1000 From: Tejun Heo To: David Carlier Cc: David Vernet , linux-kernel@vger.kernel.org Subject: Re: [PATCH] sched_ext: Separate lock and first_task into distinct cache lines in scx_dispatch_q Message-ID: References: <20260228130647.87606-1-devnexen@gmail.com> 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: <20260228130647.87606-1-devnexen@gmail.com> On Sat, Feb 28, 2026 at 01:06:47PM +0000, David Carlier wrote: > lock (write-heavy) and first_task (read-mostly, lockless RCU peek) share > the same cache line in struct scx_dispatch_q. Every lock acquire/release > by a dispatching CPU invalidates the line for all CPUs performing > lockless first_task peeks, causing unnecessary cache coherence traffic, > especially across NUMA nodes. > > Add ____cacheline_aligned_in_smp to first_task to place it on its own > cache line, eliminating this false sharing on SMP systems. On > uniprocessor builds the annotation is a no-op, so no space is wasted. > > On SMP, the trade-off is increased struct size: each scx_dispatch_q > grows by up to ~56 bytes of padding. There are two instances embedded > per-CPU in scx_rq (local_dsq and bypass_dsq), plus any dynamically > allocated custom DSQs, so the total overhead scales with the number of > CPUs and active DSQs. But first_task is read-mostly. How could it be? David, from now on, I'm not going to apply these patches unless you provide backing experimental data. Thanks. -- tejun