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