lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <30593e56-d575-4e40-8b78-b2a75a7eb822@intel.com>
Date: Thu, 11 Jan 2024 15:31:41 -0800
From: Reinette Chatre <reinette.chatre@...el.com>
To: "Luck, Tony" <tony.luck@...el.com>, Peter Newman <peternewman@...gle.com>
CC: Amit Singh Tomar <amitsinght@...vell.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "Yu, Fenghua" <fenghua.yu@...el.com>,
	"james.morse@....com" <james.morse@....com>, George Cherian
	<gcherian@...vell.com>, "robh@...nel.org" <robh@...nel.org>
Subject: Re: [EXT] Re: [RFC 00/12] ARM: MPAM: add support for priority
 partitioning control

Hi Tony,

On 1/11/2024 3:14 PM, Luck, Tony wrote:
>>> I'm not sure having multiple lines for the same resource makes anything
>>> clearer.  I preferred one of the earlier proposals like this one:
>>>
>>> 	L3:0=XXXX,PPART=X,CCAP=X;1=YYYY,CCAP=Y
>>
>> This assumes that all tools (public and private) that currently parse the schemata
>> file will be able to handle this additional information seamlessly.
> 
> Reinette,
> 
> Yes. If there are tools that *read* schemata files, they will be surprised by this extra information.
> 
> But that also applies if the "extra" information is moved to a second line that also begins with "L3:".
> 
> Tools that *write* schemata files should be OK as long as the kernel will still accept:
> 
>   # echo "L3:1=fff" > schemata
> 
> E.g. the Linux selftests in tools/testing/selftests/resctrl/ should still run without
> any modification.
> 
> The "separate line" option could work if the prefix isn't "L3:".  E.g.
> 
> L3:0=XXXX;1=YYYY
> L3PPART:0=X
> L3CCAP:0=X;1=Y
> 
> If these options are asymmetrically available on cache instances, these extra
> lines won't have every L3 cache instance listed.

I think we are going in circles here. I shared my concern about user space
breakage a while ago [1] in response to your previous proposal and this new proposal
seems to match where this thread ended [2] last year.

Reinette

[1] https://lore.kernel.org/lkml/be51596e-2e62-2fb9-4176-b0b2a2abb1d3@intel.com/
[2] https://lore.kernel.org/lkml/20230901160451.00001f75@Huawei.com/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ