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 55E173242D8 for ; Fri, 6 Feb 2026 16:15:50 +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=1770394550; cv=none; b=MSj/icfVvzZKUyS8EclaEE0E6CqNV4XLueWOQgIrNu+Rj3Ou2zokkcHqKObp+gpaCgPjFI5VuF3bZ7b4Gg6bNHkLeOhd3RHf5QOw1DjFlVnD8RlAVt4sWduD2MIlv3C//1TJIG0896bQ5vdtj0EC2yZoLW1+yX/EHkGjb7TpEII= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770394550; c=relaxed/simple; bh=/oAOaiPQLdSAOdmpoWwX0JJV8RiU0yK2dexWgz4l8YE=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=cFs56iT3iOoJqHQgYsFGVsyLcj5lZxtl3HqugydKsce4+Z1bFvdWpe7sjKVzIWbfUuDOz8PiB3Ef28683+xtNuWMuH84N/kF1WZoGB2afNmFP2bpjBjVkU4XsjFeHjQpU95EYWvevY+6D0pNwhObt3vEcm5XzpAWdcIKNVU9NiA= 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 37384339; Fri, 6 Feb 2026 08:15:43 -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 BE4B93F632; Fri, 6 Feb 2026 08:15:45 -0800 (PST) Message-ID: Date: Fri, 6 Feb 2026 16:15:44 +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: wangyushan , Jonathan Cameron , Linus Walleij Cc: 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> <2a42c4d7-c453-45a7-b569-89a3a2ee7246@huawei.com> From: Ben Horgan Content-Language: en-US In-Reply-To: <2a42c4d7-c453-45a7-b569-89a3a2ee7246@huawei.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Yushan, On 2/6/26 09:54, wangyushan wrote: > > On 2/5/2026 6:18 PM, Jonathan Cameron wrote: >> On Thu, 5 Feb 2026 10:12:33 +0100 >> Linus Walleij wrote: >> >>> 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. > > Intel cache pseudo lock requires help of IA32_PQR_ASSOC MSR, according > to [1], that register can save necessary information for processes acquired > cache pseudo locks, but Arm64 does not have the equivalent register. If you have MPAM, the per exception level MPAMx_ELy registers are somewhat equivalent. They tell you which partid and pmg identifiers the CPU is using and IA32_PQR_ASSOC tells you the closid and rmid which are much the same thing. Is there a difference that stops being equivalent in this scenario? > > [1]: https://www.intel.com/content/www/us/en/developer/articles/technical/cache-allocation-technology-usage-models.html > [...] Thanks, Ben