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 B05373EC6B4 for ; Fri, 17 Jul 2026 10:27:25 +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=1784284051; cv=none; b=pgMwBoxPjmM5i90xZXvN09tlQDd+a0I8nX6KQK5O6e9QTJ/Sx10R3qM4nw/G+j2kwb8ehBhGYdUHTectMQE+IQ1iZNt1JD/mKbiYb3FS5ZCGEH3prkU+TYgw+nwWDu0UE0LERQQujw72GSuZM0KsQkT2nicDUvmceIwK2ekF8Rw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784284051; c=relaxed/simple; bh=TqQRHsDrOzrVot+ug9Wce1agKU0hZ8wKtozpcGOTLm0=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=NNDXizyuIrYWx8931C7b7pGPWAURt9deQOu9C4MV9UaXiOHhJhP7vv18S/tSg/RYNo3CXlDScaj/RU5Feic9H8+gLVXAz1M58ZeQjGCpKpRt6CgvoOftfLmkBemGa86dtlnpn0n5upafMZSW/QmPHK6j2sqNNjTyKv+BFZqbx50= 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; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=i8zVhoS5; 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 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="i8zVhoS5" 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 67AAE1476; Fri, 17 Jul 2026 03:27:18 -0700 (PDT) Received: from [10.2.212.8] (e134344.arm.com [10.2.212.8]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 70C513F7D8; Fri, 17 Jul 2026 03:27:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1784284042; bh=TqQRHsDrOzrVot+ug9Wce1agKU0hZ8wKtozpcGOTLm0=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=i8zVhoS5yvhCP7DgN51vyCBT5wMVJTs5QegVdpSNbGj4Qu+8CEIxxnmeHjSzibK3e CUO+VTJn6y8q8hRswkTskyN9wGvvx/XGs7XFipoNYnuB943Wf4NLsc9A+Zo4xj/NF5 08zZ+oce4hPtr6RVcQFP3HY0vkdUxiz0DS70fGd8= Message-ID: Date: Fri, 17 Jul 2026 11:27:13 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Thunderbird Daily Subject: Re: [RFC] mpam,x86,fs/resctrl: Generic schema description Proof of Concept To: Reinette Chatre , "Luck, Tony" , Fenghua Yu , James Morse , Dave Martin , Babu Moger , Drew Fustini , "Chen, Yu C" Cc: Borislav Petkov , Thomas Gleixner , Dave Hansen , Peter Newman , "x86@kernel.org" , "linux-kernel@vger.kernel.org" References: <5ee87762-1898-4b62-94da-85b3e9917ecc@intel.com> <62701203-c4a3-4ec2-a9af-602e1fc15863@nvidia.com> <8f9f78dd-e3f5-4b35-bc72-0eb5dafdcedf@nvidia.com> <36163a81-9737-49e3-93ef-6c392f7272f0@intel.com> <0fc6df54-26c7-43fa-948a-528cd94937f1@arm.com> <9049378c-699a-4155-b1e4-737a1d7265d5@intel.com> <57740b97-80ee-4632-bca3-dc43cd7776c2@arm.com> <0300fd4a-7c21-4f72-8e6c-ab98e0cc7c58@arm.com> <341208a2-ed2f-4181-84f4-6d8e90813e77@intel.com> Content-Language: en-US From: Ben Horgan In-Reply-To: <341208a2-ed2f-4181-84f4-6d8e90813e77@intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Reinette, On 7/16/26 18:50, Reinette Chatre wrote: > > Hi Tony and Ben, > > On 7/16/26 9:22 AM, Ben Horgan wrote: >> Hi Tony, >> >> On 7/16/26 17:02, Luck, Tony wrote: >>>>> This was one element of original discussion that fizzled a bit since it was not obvious that user >>>>> space would behave like this. Consider, for example, from Documentation/filesystems/resctrl.rst: >>>>> >>>>> Reading/writing the schemata file >>>>> --------------------------------- >>>>> ... When writing you only need to specify those values which you wish to change. .. >>>> >>>> Yeah, I don't know but it does seem like something a user could reasonably expect to work. >>> >>> Personally I use one of two options to update schemata: >>> >>> 1) Just want to change something small: >>> # echo "MB:1=50" > schemata >>> 2) I want to make global change to some resource >>> # vi schemata >>> on L2 line: s/ffff/ff/g >>> :wq >>> >>> In case 2 every domain on every resource is written, but most of them to the existing value. >> >> We've got a user :) >> >>> >>> This may need careful consideration if the legacy "MB" lines are present together with the >>> new controls for MIN, MAX etc. >>> >>> Having a mode file to select whether legacy OR native controls are exposed would avoid >>> a lot of complexity in the kernel. Yes, that would mean a user that wants to use the new >>> native interface must add one "echo" to some startup script. >>> >>> Or perhaps yet another "rdt=" command line option to pick whether mount defaults to >>> legacy or native mode? >> >> The "rdt=" options are x86 specific so I don't think we should use them for generic resctrl. A mount >> option might be end up being convenient. > What is the recommended way for users to discover which mount options are supported > by a filesystem? I am not familiar with this area and a quick search showed that this could > be supported if user space programmatically splits the mount into distinct steps to first > discover if the filesystem's parser accepts the mount parameter before attempting to > mount the filesystem. It sounds to me as though a mount parameter would place additional > burden on user space? My thought here was that it could just be an easy way for the user to say they wanted to default to the native interface for all controls and that it would have no effect if there were no possible native controls. We would have to be careful to only introduce any command line or mount option once we have support for everything it can effect so its meaning doesn't change over time. (I'm also not really familiar with mount option usage which is why I have just talked tangentially to your question.) Thanks, Ben > > I am also concerned about how resctrl could confidently build on top of such mount option. > Would resctrl need to add new mount options to build on top of the ones introduced in the > base or would resctrl need to create two different filesystems? Both sounds like a challenge > to me. > > Reinette