Proposal for hardware configuration dependent performance limits

[Sebastian Huber]

On 16/11/2020 23:42, Chris Johns wrote:
> On 16/11/20 5:40 pm, Sebastian Huber wrote:
>> On 16/11/2020 00:33, Chris Johns wrote:
>>
>>>>>> 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?
>>>> Yes, hardware configuration.
>>> Why not make these values part of the BSP configuration? The defaults for the
>>> BSP can have a set of suitable values. Different boards have different
>>> configurations to match and a separate kernel build.
>>>
>> This doesn't work on BSPs which support configuration via a hardware
>> enumeration, boot loader settings, or device trees. Also changes in the BSP
>> options have no influence on the BSP name. Not only BSP configuration influence
>> performance, the CPU options play a role too, for example RTEMS_SMP. In order to
>> compare performance values over time we have to obtain the values under the same
>> conditions.
> Maybe I am not understanding the context.
>
> A BSP, which ever one, has a set of options that configure it. An example is the
> xilinx_zynq_zc702 and the `ZYNQ_RAM_LENGTH = 0x40000000`. If I have 2 Zynq
> circuits one with 256M and one with 1G I need to build and maintain 2 RTEMS
> builds and from a purists point of view I need to maintain 2 builds of the exact
> same application.
>
> I asked about the fixed memory and your answer was to use the BSP options, the
> size is fixed in the linker command files via the BSP option. That is what I
> have done.
>
> I would expect there exists a set of values for the xilinx_zynq_zc702 with no
> SMP and with SMP as this BSP supports SMP. Those values would match all the
> other settings for the BSP such as ZYNQ_CLOCK_CPU_1X, BSP_ARM_A9MPCORE_PERIPHCLK
> etc. If my clock is different (and they are) I would need to supply a suitable
> set of performance values if I wanted to pass those tests.
>
> I am not questioning the need for the values or the tests. I am suggesting the
> values form part of the BSP settings so a user can adjust them to suite their
> specific set up in the same way they adjust other BSP settings. I do not think
> we should attempt to hold or manage an endless sets of possible values and I do
> not see the need for complex encapsulation methods such as a base64 hashes. The
> systems we interact with are too complex and list is endless.

I think it will be highly BSP-specific what parameters are relevant to 
the performance limits. This is why I suggested to add a function which 
can be implemented by each BSP.

const char *rtems_get_hardware_performance_something();

It should return a string which changes if a performance relevant 
parameter changed. If it is only SMP/no-SMP, ZYNQ_CLOCK_CPU_1X, and 
BSP_ARM_A9MPCORE_PERIPHCLK, then fine, just return "SMP/800MHz/400MHz" 
or whatever.

My point is that we need a key reported by the BSP and then some 
performance limits which can be found by arch/bsp/key to check if there 
are performance regressions.

-- 
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/