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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
