[PATCH 2/2] cyclic: parse cyclic list only if next cyclic timestamp is reached
Rasmus Villemoes
rv at rasmusvillemoes.dk
Tue Jul 7 10:53:49 CEST 2026
On Tue, Jul 07 2026, "Patrice CHOTARD" <patrice.chotard at foss.st.com> wrote:
> On 7/6/26 18:00, Marek Vasut wrote:
>> On 7/6/26 5:16 PM, Patrice CHOTARD wrote:
>>
>> Hello Patrice,
>>
>>>>> I did a test, it doesn't bring any noticeable improvements, but nevertheless i will submit a v3 with this update.
>>>>
>>>> Does the list iteration exit when it finds the first entry that is not going to be executed at this time ? If it does not, then there will be no improvement. But for this to work, the list would have to be surely fully ordered in incrementing timestamp order, is it ?
>>>
>>> No, the list iteration parse all entries.
>>>
>>> I see your point, on original implementation, entries are not sort by incrementing timestamp order.
>>> I did some implementation test, by sorting cyclic entries in cyclic_list when :
>>> _ registering a new cyclic callback, put it directly in the right position in cyclic_list.
>>> _ in cyclic_run(), after running a cyclic, compute its next call and insrt it in the right position in cyclic_list.
>>>
>>> There is no noticeable gain.
>>
>> Did you also break from the iteration when you reached the first entry with future timestamp ? That might actually help.
>>
>
> In cyclic_run(), as now entries was sorted by increasing timestamp, only the first cyclic in cyclic_list is parsed,
> we don't need to parse all cyclic_list element.
>
The point is kind of moot as v3 seems to work just as well, but I do
want to point out that no, ensuring that the first expiring timer is at the front
does not _sort_ the list, and breaking once we hit the first non-expired
timer would be wrong. It would of course work for a list with at most
two elements, but not in general.
Rasmus
More information about the U-Boot
mailing list