From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f48.google.com (mail-wr1-f48.google.com [209.85.221.48]) (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 825211391 for ; Sat, 25 Apr 2026 00:05:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777075550; cv=none; b=nS3ObJWa5sfbCVbCq1kToQ1w1D3VK91+jWpEjHsCBUK95zQBsyLC/Nmzj8+3e6nP1gdE/2hyYmw97E4RL2F2cPucb5ItZssQXVSX+3t6/oDMFRcg147bvs8bOeRvAnoozE6ixzkjb4L1yutNU/HgMC9pCFaeqJCGna79L2twFB8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777075550; c=relaxed/simple; bh=Xk1eyWiwlPGGLQ90HdqUYJo6ibjlypYbgtc2E9fBtrg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=YcbaJxI1whJEWszDuMWQ00j4hU5cMboCrVyNge9+WDZ5JrE9u8NDxRmDfQLsCSkPU3GuBuc/zLc0IqTiwU0R2ZlR26zf2AwA0Q/ffL7T6wO56c03Z240MrBghUZPbJ40FboZtiep/CF2g055TN2zq0luvt96RILpR1FqxyMvEnk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=layalina.io; spf=pass smtp.mailfrom=layalina.io; dkim=pass (2048-bit key) header.d=layalina-io.20251104.gappssmtp.com header.i=@layalina-io.20251104.gappssmtp.com header.b=T5YBLC9L; arc=none smtp.client-ip=209.85.221.48 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=layalina.io Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=layalina.io Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=layalina-io.20251104.gappssmtp.com header.i=@layalina-io.20251104.gappssmtp.com header.b="T5YBLC9L" Received: by mail-wr1-f48.google.com with SMTP id ffacd0b85a97d-43d70b3e159so4379082f8f.0 for ; Fri, 24 Apr 2026 17:05:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=layalina-io.20251104.gappssmtp.com; s=20251104; t=1777075547; x=1777680347; 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=+DW9V2tVLmliarjXvwdY9VdV9L2zFwO+JDQN/05Fsqo=; b=T5YBLC9LayKr/71pAYdv0LqoaExdRf7KUyKoRgySeqzc135XyVn4h8HKaCdDpDrPIJ m+8m5ng/wpHRAuQ1X/4q6fgOfZPgCfhh0SP0PCPuWkwDlWa8wM2wLLUeihmXxnKkaHrq H/foyD7s15U8X/K2I4uycOiZwNuYTJriIWFAODrQgrZKjdhlrXjR61MXCGUKQTih72G3 TJVgeHNuCT/flm7+bm1JRf963/Yb/CWBX3QbHOPTf8bxCLsdH9RKWQz1iQM89yI1SXU3 pfQBucQORROC05964qb+7J7s2GUGEtPcaq3d+m68da+kqBwZkpdP5KNGZmp7fbkNE1FP c1QQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777075547; x=1777680347; 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=+DW9V2tVLmliarjXvwdY9VdV9L2zFwO+JDQN/05Fsqo=; b=CYGS/jBZNz2ljGAWzxrUEvAXdEPqGFAmgycB5vpd9qS4pp+TGk/OTDCkUPIS9ckBza QavgN8+Q3DpOF+Po2Fl8mUc7J/EMGkZ3VDNE8Pjsqq2rBA4ivUsd7Zq0a1ILx+PPRR72 QYUHBI555Cor1AEKz25vTYRtXyCaOtVhTe1pCxsYkIh+2c9D8GSsWSPq0nVwwpZF6h27 5B9Tnp+axhYZIrggvw+UfJ4Y8uiU4k3w5NoTnlR2oheAmZQxm/wOz9YCDAP8imKoTZF9 V8UPkc2K4brF5/f+7aWG2JkBMFSxuGom55aGx+KunpRO0bMx2zz5cAFBdPlJVsXgIAdm x5Jw== X-Forwarded-Encrypted: i=1; AFNElJ8XFABya8Mk6wwqWhh3MILna7gxDZKmjUIUbchXnMUq4wbSA3SeQesLAXULhv49Ka3etUvaQh2rikk31Xw=@vger.kernel.org X-Gm-Message-State: AOJu0YwCXyV/bwyjIzlrJqE+aBuc4Uu+m5flD2tPTCvWGJhry1wD1E5R G1i2AEBkTRyEuOr4lLSK9fwfOFji7azZP+ypD/r/ZE5ToJGgPpdBJgp7rmodH7zmAN8= X-Gm-Gg: AeBDiesBzfM3oqCAsd1iS8D3IqAEr4b2rXIuUPH0/xNua0NypNvHZV+4DUsSFMXAWzO 7aE5m7BTce2/Zc7mTV6+sFO+jxrai3qBqFNeVkfNeT5XCF3UEtuIRHW5A+yGYdql49HG6YxYV26 hQDSutAUwtNArzrLxx8btCUNENJSocFm3hQrzMBcyVvlc2ZibSzkrL3dvmCSH2DY+hOIC5zx1jz c4VYsdQLwC8dN98AXU0J7lPoZcDFlVBzycC/d1MilhacW1zbUAXXYWuqURgTMTecM/9ofo0Wd6B 7jfh3uWrmrG6/1T97hg8ApoXD4kS1o9asgjGeWDX2WQMxCJfOp0afdWqcQaZZhOOOD3sX777qXO hyyjmQZcedqhsWZ/Q7h3UWneMlzRr8MYEObxmiZaUtgUaTuovrC8rmhkW4Z5oZ3UwgiOi9Mc4R1 tClnZN1qZhxwIEJ+q7DKINa276wj8= X-Received: by 2002:a05:600c:34c3:b0:485:41c4:e2e4 with SMTP id 5b1f17b1804b1-488fb792dd0mr460579185e9.23.1777075546675; Fri, 24 Apr 2026 17:05:46 -0700 (PDT) Received: from airbuntu ([185.253.98.50]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-489201cde98sm376995395e9.7.2026.04.24.17.05.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Apr 2026 17:05:45 -0700 (PDT) Date: Sat, 25 Apr 2026 01:05:42 +0100 From: Qais Yousef To: "Chen, Yu C" Cc: Tim Chen , Vern Hao , Peter Zijlstra , Ingo Molnar , K Prateek Nayak , Vincent Guittot , Juri Lelli , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , Madadi Vineeth Reddy , Hillf Danton , Shrikanth Hegde , Jianyong Wu , Yangyu Chen , Tingyin Duan , Vern Hao , Len Brown , Aubrey Li , Zhao Liu , Adam Li , Aaron Lu , Tim Chen , Josh Don , Gavin Guo , Libo Chen , linux-kernel@vger.kernel.org Subject: Re: [Patch v4 00/22] Cache aware scheduling Message-ID: <20260425000542.7jibicb2bkxg7ww7@airbuntu> References: <20260416002749.muyrcycmtabksav4@airbuntu> <20260421003438.whnn2gvv4gkfcmx5@airbuntu> <83c14639f1d6baa1665ad367c308676e5f951ff7.camel@linux.intel.com> <20260423150649.y27ks53zldy2upwo@airbuntu> 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 In-Reply-To: On 04/24/26 00:48, Chen, Yu C wrote: > On 4/23/2026 11:06 PM, Qais Yousef wrote: > > On 04/21/26 13:57, Tim Chen wrote: > > > On Tue, 2026-04-21 at 01:34 +0100, Qais Yousef wrote: > > > > On 04/20/26 17:01, Chen, Yu C wrote: > > > > > On 4/16/2026 8:27 AM, Qais Yousef wrote: > > > > > > On 04/01/26 14:52, Tim Chen wrote: > > > > > > > [ ... ] > > > > > > I suppose there are two scenarios. The first is enabling/disabling > > > > > aggregation > > > > > for a group of tasks, and the second is task tagging. For the first > > > > > scenario, > > > > > this can be applied either process-wide or cgroup-wide by providing a flag, > > > > > > > > Cgroup-wide tagging doesn't make sense IMO. Process-wide yes. > > > > > > > > > > I think this depends on the usage scenario. In private discussion with > > > Vern from Tencent, he mentioned that such a cgroup based tagging is useful for them. > > > > We all want ponies :) > > > > I think this needs a why. It doesn't make sense to group procsses in general. > > It seems this requirement is tied to elaborate setup to force the kernel to > > deal with this elaborate setup in a generic manner. > > Using cgroup tagging appears to be a trade-off intended to reduce users' > overhead from interface migration. Based on feedback from several cloud > providers (Vern, please correct me if my understanding is wrong), > cgroups are the basic unit for infrastructure construction: > there could be a large process with N threads: N/2 of them > are assigned to cgroup1, and the remaining N/2 to cgroup2. Ah so the problem is single large process. Shouldn't the kernel manage that and split into LLCs automatically as part of its best effort? I don't think there's any migration cost for tagging a whole process. It is just wasting resources. Those who want to squeeze more, they have the option to do better, but don't have to. > Updating the attributes associated with a cgroup is > straightforward - using process-based aggregation might not work Why not? wake up or LB based, we should be able to see a process has loaded an LLC and spill to another LLC, no? > for this scenario - using task-based aggregation would require to > re-write the mid-layer. As mentioned above, this is the smartest opportunity to squeeze more out of the system. It will require more work yes, but totally optional too. > > > > > Anyway with the tagging approach we can easily allow process level LLC sharing > > via simple description like > > > > // shared cookie definition > > { > > "WEB_SERVICE_COOKIE": [ "nginx", "postgresql"], > > "TRANSCODING_COOKIE": [ "decoder", "encoder"] > > } > > > > Which simply tell the utility to reuse the cookie for these processes using the > > key as a unique identifier. > > > > By the way, cookie generation might need kernel help to create a unique id. > > > > Still, if someone wants such elaborate setup the first thing to suggest is > > static portioning via cpuset. Do you know why this is not sufficient? > > I suppose it is because the admin want a high system utilization by > mixing latency-sensitive tasks and batch tasks together to share the > CPU resource. Using cpuset to isolate them might bring lower utilization. Hmm yes I get and advocate that. I just don't get it if the request is to tag multiple process to share LLC. This is not cache aware scheduling, this is a partitioning problem. Note we want to use the concept to help with co-locating tasks in a single LLC to take advantage of bigger L2. Currently it seems the approach is hardwired to a particular need.