Received: by 2002:ab2:69cc:0:b0:1f4:be93:e15a with SMTP id n12csp21903lqp; Fri, 12 Apr 2024 09:25:19 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCXu5EQVKTYlAPMpq5QCllmWmdQpjd473/MGAU8QTLRA0FM9ajeGkyRTttniwfOE+gprfrLyHhmFV2ovtqdzROWOsp3RZSas0GiDa57Jfg== X-Google-Smtp-Source: AGHT+IEHjpaKSdnln34umksVOqIQCuOSkB3MCi7VAmZs5k6Xu8+78UiFPv6/GdAwxUxpgfJ97huH X-Received: by 2002:a17:903:2b0c:b0:1e2:8eee:ca5a with SMTP id mc12-20020a1709032b0c00b001e28eeeca5amr3473185plb.52.1712939119471; Fri, 12 Apr 2024 09:25:19 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1712939119; cv=pass; d=google.com; s=arc-20160816; b=ZzVfwcP98c3zRH/ulsxlajMBcpJ8ziMa2cMBQYiqKqlLi1uF2E/jQW62H1EmX90w0E 40tMu6kUDV/gtuKRzUmX0n7emXGEIAjdO5Fttc6ffWaVv0mwmG0fnLFr/wcgukNXD4JQ vGuvkpAaUlwlw73a8yFHdYym61m+19dudIQaFqAIjD+6EIBOznX3cxPjcWDE14bwYRL+ R/u8cpn42brlouy+WRLkzE4a9T/7jGcv51x1Q4SxJsnJHed/YxHznedR78q+sR1bFTIV HyxG540bDz89MqV7Im8j8AygIDGmxLJQmeIfV09RbCslk8ThNTCCWT5ZdLIOBeDb7SCd Pc2w== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-disposition:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:message-id:subject:cc :to:from:date; bh=KQxO3EZBaePANa2I1jkasH9AACjVqUPI6NHk/Gu5xtc=; fh=QpfXcl1MWRNwK/PrSFDaf8vyLNOqSjtq+qtJ/l97qlo=; b=mJi874pW4ZTFu8SVdy6G4Qwblywyzm6lphT2h/MlHYeP+mh9Mcxy+3j5TbhQ+QrYIS RGluRGMslaKPamZToI73tbqVLJMCXiQjr85JDIEp0HAGWjOLYoxXN75OapUfmo4DDjBy iB+z5lYOtms8+xnAs3Fw3BrEYSnoCvwOi1EFV1dzhe25+o5Kviy3BuCac1prdLQmla11 QD9GjCldcrfglcddGH53nslQJxIfFMcF8WDgPDYSWYEjpy1y/lmF/X7vIzHBpzPLstJj Yyhn4rH/GonvynryECmtjpGK6BPF+M/T+NJ23MaMQrEAebNR4Oe17JTGI0DUaH96AxxV LGAg==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1 spf=pass spfdomain=arm.com dmarc=pass fromdomain=arm.com); spf=pass (google.com: domain of linux-kernel+bounces-143069-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-143069-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id n12-20020a170902d2cc00b001e49ad76d62si3545009plc.108.2024.04.12.09.25.19 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 12 Apr 2024 09:25:19 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-143069-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; arc=pass (i=1 spf=pass spfdomain=arm.com dmarc=pass fromdomain=arm.com); spf=pass (google.com: domain of linux-kernel+bounces-143069-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-143069-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 24B55283633 for ; Fri, 12 Apr 2024 16:25:19 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 010C9147C7D; Fri, 12 Apr 2024 16:23:17 +0000 (UTC) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id A7B2B14900C for ; Fri, 12 Apr 2024 16:23:14 +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=1712938996; cv=none; b=dgffJG8sPajmAfXFAvPSZc3jQkVwU1voyK9T77G0ZLMLwXY7oFe5b/rPrBza7ut/XWyPVnzJ1b7DWfJ9PXWOvqBk7A1Xn2OIGNFNFg06riRtTTxRLOLOhgIfiHL8tG5ZHWsVQbKopnNCMj5pnOT8FJUz0xqq3oXL+aFEoNIDcoI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712938996; c=relaxed/simple; bh=/3mQWjfURr0ul96Te/Rzx/s+gGbTlTdAjJvHzDW9C1o=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=KrQJBKTyUGi4ACiqhMhcTS+YfaXrL9GC3krhq6swhRJpY0TqakwXk/YowgXSeSSQEGx+GSrsBsg0HWtll9/7CN1+RY8dL6reIXhBvHlJHUcOFZwVvYDSZKl3zK4iEvkfFJIhFv+YRwSNJ7AbyryPAO1WNJs8AZhwipyaP1TH5RY= 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 2B565339; Fri, 12 Apr 2024 09:23:43 -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 38AFF3F64C; Fri, 12 Apr 2024 09:23:11 -0700 (PDT) Date: Fri, 12 Apr 2024 17:23:08 +0100 From: Dave Martin To: Reinette Chatre Cc: James Morse , x86@kernel.org, linux-kernel@vger.kernel.org, Fenghua Yu , Thomas Gleixner , Ingo Molnar , Borislav Petkov , H Peter Anvin , Babu Moger , 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 , peternewman@google.com, dfustini@baylibre.com, amitsinght@marvell.com, David Hildenbrand , Rex Nie Subject: Re: [PATCH v1 29/31] fs/resctrl: Add boiler plate for external resctrl code Message-ID: References: <20240321165106.31602-1-james.morse@arm.com> <20240321165106.31602-30-james.morse@arm.com> <23afb7ff-222f-40d0-a68e-3d7b0c3df55d@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=us-ascii Content-Disposition: inline In-Reply-To: <23afb7ff-222f-40d0-a68e-3d7b0c3df55d@intel.com> On Thu, Apr 11, 2024 at 10:42:48AM -0700, Reinette Chatre wrote: > Hi Dave, > > On 4/11/2024 7:27 AM, Dave Martin wrote: > > On Mon, Apr 08, 2024 at 08:41:04PM -0700, Reinette Chatre wrote: > >> Hi James, > >> > >> On 3/21/2024 9:51 AM, James Morse wrote: > >>> Add Makefile and Kconfig for fs/resctrl. Add ARCH_HAS_CPU_RESCTRL > >>> for the common parts of the resctrl interface and make X86_CPU_RESCTRL > >>> depend on this. > >>> > >>> Signed-off-by: James Morse > >>> --- > >>> MAINTAINERS | 1 + > >>> arch/Kconfig | 8 ++++++++ > >>> arch/x86/Kconfig | 10 +++------- > >>> fs/Kconfig | 1 + > >>> fs/Makefile | 1 + > >>> fs/resctrl/Kconfig | 23 +++++++++++++++++++++++ > >>> fs/resctrl/Makefile | 3 +++ > >>> fs/resctrl/ctrlmondata.c | 0 > >>> fs/resctrl/internal.h | 0 > >>> fs/resctrl/monitor.c | 0 > >>> fs/resctrl/psuedo_lock.c | 0 > >>> fs/resctrl/rdtgroup.c | 0 > >>> include/linux/resctrl.h | 4 ++++ > >>> 13 files changed, 44 insertions(+), 7 deletions(-) > >>> create mode 100644 fs/resctrl/Kconfig > >>> create mode 100644 fs/resctrl/Makefile > >>> create mode 100644 fs/resctrl/ctrlmondata.c > >>> create mode 100644 fs/resctrl/internal.h > >>> create mode 100644 fs/resctrl/monitor.c > >>> create mode 100644 fs/resctrl/psuedo_lock.c > >>> create mode 100644 fs/resctrl/rdtgroup.c > >>> > >>> diff --git a/MAINTAINERS b/MAINTAINERS > >>> index 5621dd823e79..c49090e9c777 100644 > >>> --- a/MAINTAINERS > >>> +++ b/MAINTAINERS > >>> @@ -18543,6 +18543,7 @@ S: Supported > >>> F: Documentation/arch/x86/resctrl* > >>> F: arch/x86/include/asm/resctrl.h > >>> F: arch/x86/kernel/cpu/resctrl/ > >>> +F: fs/resctrl/ > >>> F: include/linux/resctrl*.h > >>> F: tools/testing/selftests/resctrl/ > >>> > >>> diff --git a/arch/Kconfig b/arch/Kconfig > >>> index fd18b7db2c77..131d874d6738 100644 > >>> --- a/arch/Kconfig > >>> +++ b/arch/Kconfig > >>> @@ -1406,6 +1406,14 @@ config STRICT_MODULE_RWX > >>> config ARCH_HAS_PHYS_TO_DMA > >>> bool > >>> > >>> +config ARCH_HAS_CPU_RESCTRL > >>> + bool > >>> + help > >>> + The 'resctrl' filesystem allows CPU controls of shared resources > >>> + such as caches and memory bandwidth to be configured. An architecture > >>> + selects this if it provides the arch-specific hooks for the filesystem > >>> + and needs the per-task CLOSID/RMID properties. > >> > >> Should it mention monitoring capabilities? > > > > Probably, although I wonder whether it is better to describe this just > > once, under RESCTRL_FS. Does it makes sense to have something > > like this here? > > > > An architecture selects this option to indicate that the necessary > > hooks are provided to support the common memory system usage > > monitoring and control interfaces provided by the 'resctrl' > > filesystem (see RESCTRL_FS). > > This looks good to me. Noted, thanks. > > > > > If so, I can propose this. > > > > (Details on what gets added to task_struct is maybe unnecessarily low- > > level to bother with here...) > > > >>> + > >>> config HAVE_ARCH_COMPILER_H > >>> bool > >>> help > >>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > >>> index e071e564452e..cb043543f088 100644 > >>> --- a/arch/x86/Kconfig > >>> +++ b/arch/x86/Kconfig > >>> @@ -479,8 +479,10 @@ config GOLDFISH > >>> config X86_CPU_RESCTRL > >>> bool "x86 CPU resource control support" > >>> depends on X86 && (CPU_SUP_INTEL || CPU_SUP_AMD) > >>> + depends on MISC_FILESYSTEMS > >>> select KERNFS > >> > >> Do both X86_CPU_RESCTRL and RESCTRL_FS need to select KERNFS? > > > > Hmmm, hopefully the arch backend doesn't need to re-depend on KERNFS. > > I'll note that for review. > > > > (If not, we can probably drop filesystem-related #includes from the > > remaining x86 arch code too...) > > > > [...] (I still need to look at this.) > > > >>> diff --git a/fs/Kconfig b/fs/Kconfig > >>> index a46b0cbc4d8f..d8a36383b6dc 100644 > >>> --- a/fs/Kconfig > >>> +++ b/fs/Kconfig > >>> @@ -331,6 +331,7 @@ source "fs/omfs/Kconfig" > >>> source "fs/hpfs/Kconfig" > >>> source "fs/qnx4/Kconfig" > >>> source "fs/qnx6/Kconfig" > >>> +source "fs/resctrl/Kconfig" > >>> source "fs/romfs/Kconfig" > >>> source "fs/pstore/Kconfig" > >>> source "fs/sysv/Kconfig" > >>> diff --git a/fs/Makefile b/fs/Makefile > >>> index 6ecc9b0a53f2..da6e2d028722 100644 > >>> --- a/fs/Makefile > >>> +++ b/fs/Makefile > >>> @@ -129,3 +129,4 @@ obj-$(CONFIG_EFIVAR_FS) += efivarfs/ > >>> obj-$(CONFIG_EROFS_FS) += erofs/ > >>> obj-$(CONFIG_VBOXSF_FS) += vboxsf/ > >>> obj-$(CONFIG_ZONEFS_FS) += zonefs/ > >>> +obj-$(CONFIG_RESCTRL_FS) += resctrl/ > >>> diff --git a/fs/resctrl/Kconfig b/fs/resctrl/Kconfig > >>> new file mode 100644 > >>> index 000000000000..36a1ddbe6c21 > >>> --- /dev/null > >>> +++ b/fs/resctrl/Kconfig > >> > >> Could you please review the contents of this file for > >> appropriate line length and consistent tab usage? > > > > Noted. > > > >>> @@ -0,0 +1,23 @@ > >>> +config RESCTRL_FS > >>> + bool "CPU Resource Control Filesystem (resctrl)" > >>> + depends on ARCH_HAS_CPU_RESCTRL > >>> + select KERNFS > >>> + select PROC_CPU_RESCTRL if PROC_FS > >>> + help > >>> + Resctrl is a filesystem interface > >>> + to control allocation and > >>> + monitoring of system resources > >>> + used by the CPUs. > > > > (Not quite a haiku, but I don't know how many syllables "resctrl" > > counts as...) > > > > Since this is the Kconfig user's primary knob for enabling resctrl, > > maybe flesh this out and make it a bit more generic and newbie-friendly? > > Something like: > > > > Some architectures provide hardware facilities to group tasks and > > monitor and control their usage of memory system resources such as > > caches and memory bandwidth. Examples of such facilities include > > Intel's Resource Director Technology (Intel(R) RDT) and AMD's > > Platform Quality of Service (AMD QoS). > > Nit: We should double check with AMD how they want to refer to their > feature. Their contribution to the resctrl docs used the term you provide > but their spec uses PQOS. > > Do you expect this snippet to be updated when MPAM full support lands or > does resctrl have enough support at this point to include a mention of MPAM? Probably yes, even if only to make the point that this is generic and relevant for more than one architecture. For this series, MPAM is not known to the kernel, so I didn't want to give the impression that there was any support for it (yet). > > > > If your system has the necessary support and you want to be able to > > assign tasks to groups and manipulate the associated resource > > monitors and controls from userspace, say Y here to get a mountable > > 'resctrl' filesystem that lets you do just that. > > > > If nothing mounts or prods the 'resctrl' filesystem, resource > > controls and monitors are left in a quiescent, permissive state. > > Well written, thank you. Thanks for the once-over; I'll propose this to James for inclusion. > > > > > If unsure, it is safe to say Y. > > > > See for more information. > > > > I'm assuming that just enabling this option doesn't introduce > > significant overheads. For MPAM I'm pretty sure it doesn't, > > but if this is a concern that we could go for "If unsure, say N." > > I would vote for N for when folks are not sure. OK, fair enough. Noted. Cheers ---Dave