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 91B4684DF7 for ; Tue, 23 Apr 2024 12:38:02 +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=1713875884; cv=none; b=UgKLwjNyEIj/WuvvKGRoDar7dS5Lh5iUuV7+dY91d0WIzCRra5Rrk37AEETJ7vDLLlc1qC/1bp2swIYDBkwb3WICRjfbvNCOpDAeXfNkON1QLvCbTSkFdBXuFRdZYfI5BnFRKxSsjFYK7IiyQMovkf9QW8uPUMDpmOzYwv6ZnOo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713875884; c=relaxed/simple; bh=AY5JJeDJivKChvabexTUc3tK2jPNqYuOCFzaoJVLCUU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=vDEWdeKrijfBES9Q7pSxtfkax8h/idcGhfIY40grsgS7igVFnteNk+pnJdGKo69Rvt972s1TNN5VEakbKqvqweU6WX3hZCDrsBiwhH6t5H/Bwdm5N6y8aPE1/FYHN1hS/qHFizoa74l+1Sm6+cHiW0OQVwRZRPN2Sqd+gTCdVas= 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 CF022339; Tue, 23 Apr 2024 05:38:29 -0700 (PDT) Received: from e133380.arm.com (e133380.arm.com [10.1.197.52]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 18F043F7BD; Tue, 23 Apr 2024 05:37:58 -0700 (PDT) Date: Tue, 23 Apr 2024 13:37:56 +0100 From: Dave Martin To: Peter Newman Cc: Reinette Chatre , babu.moger@amd.com, James Morse , x86@kernel.org, linux-kernel@vger.kernel.org, Fenghua Yu , Thomas Gleixner , Ingo Molnar , Borislav Petkov , H Peter Anvin , shameerali.kolothum.thodi@huawei.com, D Scott Phillips OS , carl@os.amperecomputing.com, lcherian@marvell.com, bobo.shaobowang@huawei.com, tan.shaopeng@fujitsu.com, baolin.wang@linux.alibaba.com, Jamie Iles , Xin Hao , dfustini@baylibre.com, amitsinght@marvell.com, David Hildenbrand , Rex Nie Subject: Re: [PATCH v1 00/31] x86/resctrl: Move the resctrl filesystem code to /fs/resctrl Message-ID: References: <20240321165106.31602-1-james.morse@arm.com> <94c3bfd0-e221-46c7-86c4-f0545e66f17d@amd.com> <4cf859be-294f-4db3-948c-a96b5457a10d@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 Content-Transfer-Encoding: 8bit In-Reply-To: On Mon, Apr 22, 2024 at 11:39:00AM -0700, Peter Newman wrote: > Hi Dave, > > On Mon, Apr 22, 2024 at 9:01 AM Reinette Chatre > wrote: > > > > Hi Babu and Dave, > > > > On 4/22/2024 6:51 AM, Moger, Babu wrote: > > > On 4/19/24 23:06, Reinette Chatre wrote: > > >> > > >> [1] https://lore.kernel.org/lkml/cover.1711674410.git.babu.moger@amd.com/ > > > > > > Do you have any more feedback on this series. I have few feedbacks from > > > Peter. I was planning to work on v4 of this series. > > > > > > > Babu: It is difficult to start drilling into the implementation before there > > is agreement on the interface. One reason you went through the effort of > > the first few iterations was to accommodate Arm's use cases as we understand > > it, but we need to hear from Arm if we are on the right track here. > > I do hope that we will hear something in the next couple of weeks. > > > > Dave: Could you please check in if the interface introduced [1] is something > > of interest to Arm? If it is not, we can proceed with the implementation without > > trying to consider how Arm may use/need such an interface. If it is, could you > > please let us know when we can expect feedback from Arm? > > Because MPAM implementations typically expose an MSC for each DRAM > channel, there is an alternate strategy we can use for the monitor > scalability problem: > > When a single DRAM MSC does not provide enough monitors to track all > of the supported PARTID x PMG combinations simultaneously, the DRAM > MSCs collectively may provide a sufficient number of monitors. > Therefore, as long as the distribution of traffic among the DRAM > channels is uniform (or predictably non-uniform), it's possible to > estimate the total bandwidth with sufficient accuracy. > > -Peter > So you're suggesting that if (say) DRAM traffic is striped symmetrically across N channels, and each has counters, then a counter matching PARTID:PMG on just one channel should given an unbiased estimate of the traffic from that group (with some sacrifice of precision, and assuming the workload is non-pathological)? I guess that could work, though this might work badly for some workloads and might give a malicious workload a way to hide transactions from monitoring if the placement of the counter is too fixed and/or predictable. Cheers ---Dave