On 7/2/26 16:32, Patrice CHOTARD wrote:
>
>
> On 7/1/26 09:24, Marek Vasut wrote:
>> On 7/1/26 8:27 AM, Patrice CHOTARD wrote:
>>
>> Hello Patrice,
>>
>>>> What takes 700ms in sleep_thread() , surely not schedule() ?
>>>
>>> Hi Marek
>>>
>>> On STM32MP157C-dk2, each schedule() execution takes between 2 and 4us
>>> depending of the cyclics function to execute.
>>
>> That is about 1100 instructions on 650 MHz CA7 which is way too much , I
>> think that is the problem we need to solve first.
>>
>> Look ta common/cyclic.c schedule() , I think it is the list iteration in
>> cyclic_run() that takes forever. And I think the fix is simple, let the list
>> iteration surely run through once on the first run of cyclic_run(), and
>> while it is running, for each entry, figure out when the entry should be run
>> NEXT, and note the NEXT run timestamp down. At the end of cyclic_run(),
>> figure out when the nearest NEXT timestamp is (you can do that as part of
>> the list iteration of course), and store that information in some global
>> variable. Finally, add at the beginning of cyclic_run() a test whether this
>> timestamp was reached. If not, do nothing, because you already know that
>> nothing has to be executed yet, and you will avoid the expensive list
>> traversal this way.
>>
>> That should make the execution time of cyclic_run() negligible for the
>> majority case.
>>
>> What do you think ?
>
>
> Hi Marek
>
> Agree with your analysis, i will send a fix to exit from cyclic_run() in case
> the next cyclic timestamp is not reached.
> But, in parallel, to gain more reactivity, schedule() can also be moved at
> the same level of ctrcl() as this patch is proposing.
>
> Thanks
> Patrice
>
For information, the cyclic_run() update series is available here :
https://patchwork.ozlabs.org/project/uboot/list/?series=511795
Thanks
Patrice
