Re: Proposal for hardware configuration dependent performance limits

[Chris Johns]

On 21/11/20 3:43 am, Gedare Bloom wrote:
> On Thu, Nov 19, 2020 at 4:51 PM Chris Johns  wrote:
>>
>> On 19/11/20 7:26 pm, Sebastian Huber wrote:
>>> Hello Chris,
>>>
>>> On 17/11/2020 22:43, Chris Johns wrote:
>>>

 On 17/11/20 6:14 pm, Sebastian Huber wrote:
> 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.05
>>>mean-upper-bound: 0.05
>>>  FullCache:
>>>max-upper-bound: 0.05
>>>mean-upper-bound: 0.05
>>>  HotCache:
>>>max-upper-bound: 0.05
>>>mean-upper-bound: 0.05
>>>  Load/1:
>>>max-upper-bound: 0.1
>>>mean-upper-bound: 0.1
>>>  Load/2:
>>>max-upper-bound: 0.1
>>>mean-upper-bound: 0.1
>>>  Load/3:
>>>max-upper-bound: 0.1
>>>mean-upper-bound: 0.1
>>>  Load/4:
>>>max-upper-bound: 0.1
>>>mean-upper-bound: 0.1
>>>
>>> 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 = 0x4000`. 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.
 I suggest you avoid heading down a path of specific strings, ie avoid 
 something
 meaningful a human can read. Also performance characteristics are 

Re: [PATCH 2/3] score: Add CONFIGURE_INIT_TASK_STORAGE_SIZE

[Chris Johns]

On 20/11/20 7:31 pm, Sebastian Huber wrote:
> In order to better support applications which use the new
> rtems_task_construct() directive add the
> CONFIGURE_INIT_TASK_STORAGE_SIZE configuration option.  If this option
> is specified, then the Classic API initialization task is constructed
> with rtems_task_construct().
The name CONFIGURE_INIT_TASK_STORAGE_SIZE does not reflect the role described
here and is a little ambiguous unless you know the implementation detail.

CONFIGURE_INIT_TASK_CONSTRUCT_STORAGE_SIZE ?

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2 2/2] libtests/ofw01: Added a test for RTEMS OFW

[Christian Mauderer]

Hello Niteesh,

Am 20.11.20 um 20:18 schrieb Niteesh G. S.:
On Fri, Nov 20, 2020 at 2:50 PM Christian Mauderer 
> wrote:


On a last test before I wanted to push it, I found a problem
(sorry). On
BSPs that rely on a FDT the test doesn't work:

No problem :).

You wrap bsp_fdt_get and return another FDT. So as soon as one
driver of
the BSP needs the original FDT, that driver won't work any more.

I think I remember that problem from the Beagle too. Didn't you have a
version where you have enabled the wrapper later? If not: I added a
suggestion below.

Really sorry since it has been a couple of months now I don't exactly
remember what all I tried.


No problem. It's partial my fault that it needed that much time.




Am 03.11.20 um 19:18 schrieb G S Niteesh Babu:
 > Added a basic test for the implemented RTEMS OFW
 > API.
 > ---
 >   spec/build/testsuites/libtests/grp.yml   |   2 +
 >   spec/build/testsuites/libtests/ofw01.yml |  21 +++
 >   testsuites/libtests/ofw01/init.c         | 187
+++
 >   testsuites/libtests/ofw01/ofw01.doc      |  29 
 >   testsuites/libtests/ofw01/ofw01.scn      |   2 +
 >   testsuites/libtests/ofw01/some.c         |  72 +
 >   testsuites/libtests/ofw01/some.dts       |  76 +
 >   testsuites/libtests/ofw01/some.h         |  15 ++
 >   8 files changed, 404 insertions(+)
 >   create mode 100644 spec/build/testsuites/libtests/ofw01.yml
 >   create mode 100644 testsuites/libtests/ofw01/init.c
 >   create mode 100644 testsuites/libtests/ofw01/ofw01.doc
 >   create mode 100644 testsuites/libtests/ofw01/ofw01.scn
 >   create mode 100644 testsuites/libtests/ofw01/some.c
 >   create mode 100644 testsuites/libtests/ofw01/some.dts
 >   create mode 100644 testsuites/libtests/ofw01/some.h
 >
 > diff --git a/spec/build/testsuites/libtests/grp.yml
b/spec/build/testsuites/libtests/grp.yml
 > index b9ca014b0d..1aa136854a 100644
 > --- a/spec/build/testsuites/libtests/grp.yml
 > +++ b/spec/build/testsuites/libtests/grp.yml
 > @@ -316,6 +316,8 @@ links:
 >     uid: write
 >   - role: build-dependency
 >     uid: writev
 > +- role: build-dependency
 > +  uid: ofw01
 >   type: build
 >   use-after:
 >   - rtemstest
 > diff --git a/spec/build/testsuites/libtests/ofw01.yml
b/spec/build/testsuites/libtests/ofw01.yml
 > new file mode 100644
 > index 00..8517c58bad
 > --- /dev/null
 > +++ b/spec/build/testsuites/libtests/ofw01.yml
 > @@ -0,0 +1,21 @@
 > +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
 > +build-type: test-program
 > +cflags: []
 > +copyrights:
 > +- Copyright (C) 2020 Niteesh G S
 > +cppflags: []
 > +cxxflags: []
 > +enabled-by: true
 > +features: c cprogram
 > +includes: []
 > +ldflags:
 > +- -Wl,--wrap=bsp_fdt_get
 > +links: []
 > +source:
 > +- testsuites/libtests/ofw01/init.c
 > +- testsuites/libtests/ofw01/some.c
 > +stlib: []
 > +target: testsuites/libtests/ofw01.exe
 > +type: build
 > +use-after: []
 > +use-before: []
 > diff --git a/testsuites/libtests/ofw01/init.c
b/testsuites/libtests/ofw01/init.c
 > new file mode 100644
 > index 00..82ee5eb11f
 > --- /dev/null
 > +++ b/testsuites/libtests/ofw01/init.c
 > @@ -0,0 +1,187 @@
 > +/* SPDX-License-Identifier: BSD-2-Clause */
 > +
 > +/*
 > + * Copyright (C) <2020> Niteesh G S mailto:niteesh...@gmail.com>>
 > + *
 > + * Redistribution and use in source and binary forms, with or
without
 > + * modification, are permitted provided that the following
conditions
 > + * are met:
 > + * 1. Redistributions of source code must retain the above copyright
 > + *    notice, this list of conditions and the following disclaimer.
 > + * 2. Redistributions in binary form must reproduce the above
copyright
 > + *    notice, this list of conditions and the following
disclaimer in the
 > + *    documentation and/or other materials provided with the
distribution.
 > + *
 > + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
CONTRIBUTORS "AS IS"
 > + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE
 > + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR PURPOSE
 > + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
CONTRIBUTORS BE
 > + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
EXEMPLARY, OR
 > + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF
 > + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
OR BUSINESS
 > + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
WHETHER IN