From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta1.migadu.com (out-253.mta1.migadu.com [95.215.58.253]) (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 0665A4A3851 for ; Mon, 31 Aug 2026 14:39:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.253 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788187191; cv=none; b=Q2/JGd5dU5q8kaFFf6KoHAuQMi/wfrnxAiDLgCJBWnL3CbTME6yAs/8GzJ0WdE7LkKNUbD5MRvQ24tVqKHCZN3brDY8Bn4s/TtnKTjg7z0+qbW4olFrG10fzT4pYWeBqWixj6DxPfq1wt68RFZR9N/flXZ+3jHciMEtoo1OUXSY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788187191; c=relaxed/simple; bh=RDses7JcBCw+jya5iQzYcg6OrFwbWpbRoBvLO73VAbo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=BnB+KP5w1JrUpEVexPtvh4iQtgP+VfXumUS6o9SEf2njzmfuxQ+G55hcP8HFp8OL2E3YC3q0G5y7H+wSixa0dHuvaYxM1E4O2ZxSVmxhTdDOPZ+8D3iXEWzpIKh6E/JmdjhGFlQyIEMXcesFOfreULQyABWfWp5B0dV8BOXsYBY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=iDFIFF9c; arc=none smtp.client-ip=95.215.58.253 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="iDFIFF9c" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=RDses7JcBCw+jya5iQzYcg6OrFwbWpbRoBvLO73VAbo=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1788187186; v=1; x=1788791986; b=iDFIFF9cv4YEth7lifb0ooBn/W4WAka04oTMFZ7kFt54O4e1tmrrLgeomn9a5nz9xDDvB8su SDEfQcYZozne5poZOjQ0zvUY4hl+7sxq7p8Xa9LCB23417pZenStT/sSoD56fVipJ2MeLQRV3sG Vqw4yuYBUiu7RYuoj07msI7E= X-Envelope-To: linux-kernel@vger.kernel.org Received: by smtp.migadu.com with ESMTPS id 0ec48833378b7742; Mon, 31 Aug 2026 14:39:46 +0000 X-Mizu-Trace-ID: 0ec48833378b7742 X-Migadu-Flow: FLOW_OUT Date: Mon, 31 Aug 2026 22:39:21 +0800 From: Chen Yu To: Peter Zijlstra Cc: Tim Chen , Ingo Molnar , Vincent Guittot , Qais Yousef , K Prateek Nayak , Juri Lelli , Dietmar Eggemann , Valentin Schneider , Madadi Vineeth Reddy , Shrikanth Hegde , Jianyong Wu , Yangyu Chen , Tingyin Duan , Vern Hao , Vern Hao , Len Brown , Aubrey Li , Zhao Liu , Chen Yu , Chen Yu , Adam Li , Aaron Lu , Tim Chen , Josh Don , Luo Gengkun , Gavin Guo , Yi Lai , Ricardo Neri , linux-kernel@vger.kernel.org, linux-api@vger.kernel.org Subject: Re: [RFC PATCH 0/7] sched/cache: Per-task control of cache aware scheduling via prctl Message-ID: References: <20260829092721.GB776954@noisy.programming.kicks-ass.net> 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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20260829092721.GB776954@noisy.programming.kicks-ass.net> Hi Peter, On Sat, Aug 29, 2026 at 11:27:21AM +0200, Peter Zijlstra wrote: > Subject: Re: [RFC PATCH 0/7] sched/cache: Per-task control of cache aware > scheduling via prctl > > On Fri, Aug 28, 2026 at 03:29:07PM -0700, Tim Chen wrote: > > > Feedbacks very welcome, especially on the interface shape (prctl vs. a QoS > > attribute), the kernel-owned-cookie choice, and whether the always/advise/ > > never policy composition is the right model. > > Who would be using this -- what workload prompted you do do this etc. > One motivation is that some cloud users would like finer-grained control over cache‑aware scheduling. Vern Hao from Tencent previously asked about this: https://lore.kernel.org/all/7d5bb7c4-abc5-470e-84fe-72a3b1d3a2f4@gmail.com/ and mentioned that, in their production environment, threads within the same process do not always share data. On the other hand, it is possible that within one process there are two thread groups, A and B. Threads in group A share data with each other, while threads in group B do not. Typically, in Vern's environment, group A and group B are cgroups. Group A usually runs memory‑intensive workloads, such as KV‑cache related ones, and such workloads have intensive data sharing among themselves, so they would like to enable cache‑aware scheduling separately. Furthermore, since group A is memory‑intensive, the default cache‑aware scheduling threshold might reject aggregation because group A's memory footprint is high. As a result, group A has a requirement to turn the threshold parameter separately. thanks, Chenyu