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] [thread-next>] [day] [month] [year] [list]
Message-ID: <SJ1PR11MB608365E9966D30A96B9C9B3DFC1CA@SJ1PR11MB6083.namprd11.prod.outlook.com>
Date:   Wed, 23 Aug 2023 22:36:38 +0000
From:   "Luck, Tony" <tony.luck@...el.com>
To:     "Chatre, Reinette" <reinette.chatre@...el.com>,
        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>
CC:     "Yu, Fenghua" <fenghua.yu@...el.com>,
        "james.morse@....com" <james.morse@....com>,
        George Cherian <gcherian@...vell.com>,
        "robh@...nel.org" <robh@...nel.org>,
        "peternewman@...gle.com" <peternewman@...gle.com>
Subject: RE: [EXT] Re: [RFC 00/12] ARM: MPAM: add support for priority
 partitioning control

> I see. I do have a similar concern as Peter regarding the impact of
> this change on parsing of the schemata file. I peeked at intel-cmt-cat's
> implementation [1] and if I understand it correctly these changes will
> break it. This is just one example but I do think this will have
> significant impact on user space that should be avoided.
>
> Apart from this this discussion focused on the display of properties when
> user views the schemata file. We also need to consider
> how the user will provide new data by writing to the schemata file.
> For example, I do not think it is convenient for the user to
> have to provide the allocation bitmask every time the
> "Priority partitioning" value needs to be changed for a resource
> instance. This may also be solved when considering Peter's idea but
> since this work depends on other work that is not upstream it
> is difficult to envision the impact of any suggestions.

Would if be better to add additional files? E.g. keep the syntax of
the schemata file the same. Just specifying the cache allocation
bitmask for each cache instance.

Then have a separate file (or files) for these additional attributes
like PPART and CCAP.

How are these likely to be used in practice? Would a user need to
update all of these at once (in which case separate files would be
inconvenient). Or is is likely that updates to mask, PPART, CCAP
are orthogonal, and so updates are not usually done together?

-Tony

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ