From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f53.google.com (mail-ej1-f53.google.com [209.85.218.53]) (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 E66201397 for ; Sat, 25 Apr 2026 00:14:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777076085; cv=none; b=Z67TnGX7HeEBtoAJSIxETw+o8i1dBmDYcw7hnVPPpqyetAXsBkPAC57Vf8CqW0ZB4FaGXSiBN+fCTRukZEI7e5C30BwVqUJcspifHrijttuWBw1BSlsM0lKIY4oAecct5zUD9ea5yOlfA24TpC6Bb2iXNWyNnQ1rmBfJlmJPMMA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777076085; c=relaxed/simple; bh=nhd5XmssPHW9iTVeLam8vObdZMriQj5GhAOawJli5Wg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=pNHd2t4fxgIsxqVaE8lr9W5GwkwTJCEuiJqFOkt5dlecJlx8Y6TrDFJESjpF3si6ohDSpLBOOKpnREiACTZzLggcY5meWtxszszNfOwgOc9BEqJCHZFcEvLC8s/K2U/TI631kt7q3pLO38GTPxnrOLcRQQ+L26YxZNoSnXts4wY= 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=asCH2OYW; arc=none smtp.client-ip=209.85.218.53 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="asCH2OYW" Received: by mail-ej1-f53.google.com with SMTP id a640c23a62f3a-bad54961385so313805666b.2 for ; Fri, 24 Apr 2026 17:14:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=layalina-io.20251104.gappssmtp.com; s=20251104; t=1777076082; x=1777680882; 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=CkH1XwgmTiRgidmZk3t2Jqk/AE1uXlDMss6GXMKOQWc=; b=asCH2OYWwcvOu1Qi/zG49ajGelT/atCYEMGm3E5N03sDmR4ZzgVr7AcjMCZcX9A6GL Q706Ez9tgIVdH+/kBQoW0HBEL7Mm5T0ZprSES8KfsIGKdKwOJUmN66cn4KW4Wxi5a//d T+m9N/bItQUbubUAWvuL3zG1IYIhEPZSgCoPihjLv7BC672VWJJzC8vOGUR3qCNiQjmt oE85dM3M3513wIRK1xOqfGfXEeZga25MQWJZxOOWn0BTqjWCW3Jpjw+un2DiTVzHBEMv mTh737FUGarSoi/MSKk+7XoWr5mzEwot+HVAHo9X/BMmLtV/TCqRw09EN3MdbR4Ub8tf fnUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777076082; x=1777680882; 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=CkH1XwgmTiRgidmZk3t2Jqk/AE1uXlDMss6GXMKOQWc=; b=RWM4UvwgGNuPBes7w78rc4irazTMcbAQ8GfSwFjvKezzfjH0SO2Keb0k5gh+29JgLo 5ZfN66o3QMsV4nyalzNh7S0RUqOO/e14B6PIxBFJbkIsjmiaKJb9WArbLYbKGIBWnah8 h67ewHxK5n0/XmrqydQAiina+1wMmoGLPQ6F79HZYl1IhnhwY6BvqQuGrNUy1Brd7CmB 1xJsg7cC6kdSDltO13ToDhPwhL5gBUi/I0XQI5UaTlSfBtElIbqqloNFpn51ACgWRs6B fm3vDv2bo6KZoaDpMPirTfN5XaQiLkg0jQNhJDr2KtqzQik85eMkuhea0/YG9MEX7NGc d0bg== X-Forwarded-Encrypted: i=1; AFNElJ82PmWqkeVUSzXfFGI4G8e+JB8x/+m6cf+mb8CtcNw8EMBH/kA4RV0mjbGV7icoOlZ0ColSkCnqHpJOn4o=@vger.kernel.org X-Gm-Message-State: AOJu0Yxvq5ayiOyqwLiU1b8ZqU6Qhc0NvPuywLcVNc71MJN+iP+ZK4UX zKE+EBir7X4m6sKFP6/tlRTch9VlXTSRTu80X1BkyTXHmSZJBLNKtAhsvCl3q3AHfxs= X-Gm-Gg: AeBDietmcIR7Cb95Sie3JmYIvYCN7bQIRAJBioMSX+4q4dTQ+z3r3+mz1prl/v7muNn mxH/rMo6pyoIYCt/QseITk0Q+i4fCJ9TzLlJPfTQthtbmxez17W7YN7upQBjyXKfwCIKnFphEx0 cAUiTZtfXbel3H9RTB91bmLygD2YoJruYo35lG75bcWPpyKSFOv9hPDfR33ASwfKMjbwbJSjpL7 jOdoVx52RQqYqnbURrQPuXwqGPtb56gzmGZLzAgmB6bTlGPNF2PqkFo+WHyxjL8YlUlTYQSchG3 LN/cfzskHi9mIAnPlWWoDMVyvSdljbNKJzDETRBC4JUn2RcrZ+JF/kuB8KYcFZwY29efNYzPyDD KPZ0fv93jBVCNsz3sZxn/xJWJpmjT8K6d8T9QznVeZAMp595u8Y4dQw+u/pMa3cqTUAtdRsYhzX WiM2TWGr6dKLxN4gmlXaDL1LO8z7E= X-Received: by 2002:a17:907:9806:b0:b9b:63af:d9cf with SMTP id a640c23a62f3a-ba41c1b0de6mr1482419466b.48.1777076082161; Fri, 24 Apr 2026 17:14:42 -0700 (PDT) Received: from airbuntu ([185.253.98.50]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ba454d1b694sm845046766b.29.2026.04.24.17.14.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Apr 2026 17:14:41 -0700 (PDT) Date: Sat, 25 Apr 2026 01:14:38 +0100 From: Qais Yousef To: "Chen, Yu C" Cc: Tim Chen , Peter Zijlstra , Ingo Molnar , K Prateek Nayak , "Gautham R . Shenoy" , 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 , Vern Hao , Len Brown , Aubrey Li , Zhao Liu , Chen Yu , 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: <20260425001438.xroo3orrlmwp2rcb@airbuntu> References: <20260416002749.muyrcycmtabksav4@airbuntu> <20260421003438.whnn2gvv4gkfcmx5@airbuntu> <72da6ff8-142c-4135-9b1a-5dbb30ecf7fd@intel.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=utf-8 Content-Disposition: inline In-Reply-To: <72da6ff8-142c-4135-9b1a-5dbb30ecf7fd@intel.com> On 04/24/26 01:17, Chen, Yu C wrote: > On 4/21/2026 8:34 AM, 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: > > > > > > [ ... ] > > > > > > It seems to me that there are multiple use cases. In one scenario, > > > the administrator (including daemons) is responsible for tagging > > > workloads. In another, users prefer the OS to handle automatic > > > placement without any userspace involvement. > > > > How do you define this automatic placement? AFAICS you're just grouping all > > tasks of a specific process to stay within the same LLC and hitting overcommit > > issues which you're workingaround with this load balancer only based approach? > > > > I think in practice there will be many corner cases where state is not optimal > > and we'd end up with heuristics to 'balance' things out and sensitivity to > > independent changes disturbing this fragile balance causing weird regressions > > and us slowly has less flexibility to move and shuffle code (okay, maybe too > > much doom and gloom, but we've been by this in the past :)). > > > > I am not sure how many of these tests stressed the system with multiple > > critical processes running concurrently? > > > > In the initial RFC patches, we ran multi-process tests, > where workloads were assigned by cache-aware LB to dedicated > LLCs when under-loaded. I just conducted additional > multi-process hackbench tests, and the results demonstrate > improved stabilization with cache-aware LB enabled. Thus, > I think for multi-process cases, there is no difference from > single-process cases - the tasks can be aggregated to one LLC > as long as it is under-loaded, no matter what process this > migrating task belongs to. Multi as in > num_llcs? Doing my own tests with schedqos and monitor the schedqos log, I was surprised how many processes are created from simplest of operations. My worry is that since you assume all processes must be grouped, in real life scenario you will end up with processes > num_llc in many corner cases. With opt-in approach, you know exactly how many there will be and admins can design for it. > > > By making it a userspace problem they have to figure out the right balance and > > we can focus on providing the right mechanism. > > > > I totally agree that with the help from userspace, the task aggregation > would become more usable. The test data would speak. Once we have resolved > the issues reported by Sashiko we will evaluate the schedqos provided > interface. Great. Happy to work closely with you to help iron out problems.