I don't understand this proposal. Is this an approach used somewhere else where I can review how this works? If not I need a clearer explanation.
> On Nov 13, 2020, at 14:01 , Gedare Bloom <ged...@rtems.org> wrote: > > On Fri, Nov 13, 2020 at 3:48 AM Sebastian Huber > <sebastian.hu...@embedded-brains.de> wrote: >> >> Hello, >> >> there is one aspect with respect to performance limits which is >> currently not considered in this proposal: >> >> https://lists.rtems.org/pipermail/devel/2020-November/063213.html >> >> You can run the some BSPs such as sparc/gr712rc on several boards. >> However, each board may have different settings which affect the system >> performance, for example the CPU frequency, memory controller settings, >> memory chips, etc. In the proposal, limits are specified like this: >> >> >> limits: >> sparc/gr712rc: >> DirtyCache: >> max-upper-bound: 0.000005 >> mean-upper-bound: 0.000005 >> FullCache: >> max-upper-bound: 0.000005 >> mean-upper-bound: 0.000005 >> HotCache: >> max-upper-bound: 0.000005 >> mean-upper-bound: 0.000005 >> Load/1: >> max-upper-bound: 0.00001 >> mean-upper-bound: 0.00001 >> Load/2: >> max-upper-bound: 0.00001 >> mean-upper-bound: 0.00001 >> Load/3: >> max-upper-bound: 0.00001 >> mean-upper-bound: 0.00001 >> Load/4: >> max-upper-bound: 0.00001 >> mean-upper-bound: 0.00001 >> >> This neglects that the limits are subject to a board configuration. One >> approach to cover this is the addition of a new BSP provided function: >> >> const char *rtems_get_hardware_performance_hash(); >> >> The BSP feeds all performance related data into a hash function and > "data" here means configuration? > >> returns a string encoding (for example a MD5 digest in base64 encoding). >> The example from above with the performance hash: >> >> limits: >> sparc/gr712rc/XrY7u+Ae7tCTyyK7j1rNww==: >> DirtyCache: >> max-upper-bound: 0.000005 >> mean-upper-bound: 0.000005 >> >> The test suite could report the performance has and a test output analyser >> coudl check that the reported values are in the specified bounds. >> > This will work for fixed sets of configurations. I wonder if it is > reasonable instead to define ranges over configuration values? Or to > use board variant mnemonic names instead? How many possible > configurations are we talking about? > > The hash output is fairly opaque, and really small configuration > changes would result in totally different hashes, so if I change a > board from 2 MiB RAM to 3 MiB RAM, I might like to know which > configuration this is closest to in case there is no matching hash. > > To invert the hash we will need to keep the table of all the > configurations mapped to hash values, which is fine I suppose. > > I can see that the advantage of a hash is that we don't need to create > a namespace for configuration options that may influence performance. > This can give some flexibility for boards that have different sets of > configuration options that matter. > > >> -- >> embedded brains GmbH >> Sebastian HUBER >> Dornierstr. 4 >> 82178 Puchheim >> Germany >> email: sebastian.hu...@embedded-brains.de >> Phone: +49-89-18 94 741 - 16 >> Fax: +49-89-18 94 741 - 08 >> PGP: Public key available on request. >> >> embedded brains GmbH >> Registergericht: Amtsgericht München >> Registernummer: HRB 157899 >> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler >> Unsere Datenschutzerklärung finden Sie hier: >> https://embedded-brains.de/datenschutzerklaerung/ >> >> _______________________________________________ >> devel mailing list >> devel@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel Peter ----------------- Peter Dufault HD Associates, Inc. Software and System Engineering This email is delivered through the public internet using protocols subject to interception and tampering.
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel