Proposal for hardware configuration dependent performance limits

[Peter Dufault]

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 <gedare at rtems.org> wrote:
> 
> On Fri, Nov 13, 2020 at 3:48 AM Sebastian Huber
> <sebastian.huber at 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.huber at 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 at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
> _______________________________________________
> devel mailing list
> devel at 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 235 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.rtems.org/pipermail/devel/attachments/20201113/6fdfaad1/attachment.bin>