From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id A39D73F0741 for ; Thu, 5 Feb 2026 14:37:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770302229; cv=none; b=cQHnKZ7PfK/bURJETvMyTH93ICZ+uSUgjPHJPjPk9DSE68mOu7iXLyCEqKnU7QosqNSWsuYgfkSM9OvCkUwq8bw1QClEaUCNpDL/cxP51vlh1+DKUiKegUcbxDGihOTDn1fEn+F3CeioJAZYEwTk1Ir+avRWokr4rrE3QoeOSSE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770302229; c=relaxed/simple; bh=FcvIFjLlmrDIYIBSdeM0rGaHmQXSj3M7xYFslFPOPT0=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=iFv5ISWCGBFS5zv8K0B+HGsJu2Xo8EUjZownyi4tHSe16Z+AbvcGP+vdiO25MWQBjsv0svJA2PtKRxJx+ytKuIGTAlW4PE1JG0NDzy3l3R5EyMQYpo8VeXfyPKiiMhyyCQbUiOtyf8QdI3GjwY0yHgA9bt7K7mcNdelAIdTzKjs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 81FD8339; Thu, 5 Feb 2026 06:37:02 -0800 (PST) Received: from [10.1.196.46] (e134344.arm.com [10.1.196.46]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 189DB3F632; Thu, 5 Feb 2026 06:37:04 -0800 (PST) Message-ID: <3d14457d-a510-45b0-811f-347aac5cfda8@arm.com> Date: Thu, 5 Feb 2026 14:37:03 +0000 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/3] soc cache: L3 cache driver for HiSilicon SoC To: Jonathan Cameron , Linus Walleij Cc: Yushan Wang , alexandre.belloni@bootlin.com, arnd@arndb.de, fustini@kernel.org, krzk@kernel.org, linus.walleij@linaro.org, will@kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, fanghao11@huawei.com, linuxarm@huawei.com, liuyonglong@huawei.com, prime.zeng@hisilicon.com, wangzhou1@hisilicon.com, xuwei5@hisilicon.com, linux-mm@vger.kernel.org, SeongJae Park , reinette.chatre@intel.com, james.morse@arm.com, Zeng Heng , Tony Luck , Dave Martin , Babu Moger References: <20260203161843.649417-1-wangyushan12@huawei.com> <20260203161843.649417-2-wangyushan12@huawei.com> <20260204134020.00002393@huawei.com> <20260205101814.000072ec@huawei.com> From: Ben Horgan Content-Language: en-US In-Reply-To: <20260205101814.000072ec@huawei.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 2/5/26 10:18, Jonathan Cameron wrote: > On Thu, 5 Feb 2026 10:12:33 +0100 > Linus Walleij wrote: > >> Hi Jonathan, >> >> thanks for stepping in, I'm trying to be healthy sceptical here... >> >> What you and others need to do is to tell me if I'm being too >> critical. But right now it feels like I need some more senior >> MM developers to tell me to be a good boy and let this >> hack patch slip before I shut up ;) > > It's good to have these discussions as it makes us actually > explain what they want to do much more clearly! > wangyushan and I have both been taking about this for too long so > it's easy to miss that it's not been explained properly. > > Note I was absolutely expecting a non trivial discussion on how to do > this and in particular how generic it should be. > > +CC a various resctl / mpam related people. [...] > >> >> But does the developer know if that hard kernel is importantest >> taken into account all other processes running on the system, >> and what happens if several processes say they have >> such hard kernels? Who will arbitrate? That is usually the >> kernels job. > > Take the closest example to this which is resctl (mpam on arm). > This actually has a feature that smells a bit like this. > Pseudo-cache locking. > > https://docs.kernel.org/filesystems/resctrl.html#cache-pseudo-locking > > My understanding is that the semantics of that don't align perfectly > with what we have here. Yushan can you add more on why we didn't > try to fit into that scheme? Other than the obvious bit that more > general upstream support for the arch definitions of MPAM is a work in > progress and fitting vendor specific features on top will be tricky > for a while at least. The hardware here is also independent of the > MPAM support. > > Resctl puts the control on resource allocation into the hands of > userspace (in that case via cgroups etc as it's process level controls). > The cache lockdown is a weird because you have go through a dance of > creating a temporary setup, demand fetching the lines into cache and > then rely on various operations not occuring that might push them out > again. > > Resctl provides many footguns and is (I believe) used by administrators > who are very careful in how they use it. Note that there are some guards > in this new code to only allow locking a portion of the l3. We also rely > somewhat on the uarch and cache design to ensure it is safe to do this > type of locking (other than reducing perf of other tasks). > I'm dancing around uarch details here that I would need to go seek > agreement to share more on. > Just wondering about the compatiblity of cache lockdown and resctrl/mpam. If this is done outside resctrl then how would this interact with the cache portion bitmaps used in resctrl/mpam? For instance, how would a user know whether or not a resctrl/mpam cache portion is unusable because it has been locked? Thanks, Ben