Proposal for hardware configuration dependent performance limits

[Chris Johns]

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.

Chris