On 9/9/26 04:38, Marek Vasut wrote:
> On 8/18/26 10:52 AM, Patrice CHOTARD wrote:
>
> Hello Patrice,
>
>>>> Yes, It's possible to optimize schedule() call.
>>>> Since commit 4b6a3e860878 ("usb: gadget: f_mass_storage: Add schedule() in
>>>> sleep_thread()")
>>>> schedule is called on every for() loop iteration.
>>>>
>>>> Schedule() can be called only if needed, ie if
>>>> g_dnl_board_usb_cable_connected() is not overloaded.
>>>> I well send a patch for this.
>>> My question is, whether it is possible for the schedule() call to determine
>>> whether or not it has to do (a lot of, lengthy, expensive) work or not,
>>> instead of patching the USB stack.
>>
>> To remind you, initially, it was to avoid a watchdog timeout in case
>> g_dnl_board_usb_cable_connected()
>> is not overloaded and no USB cable plugged.
>>
>> As now watchdog is managed by schedule(), we have no choice to call
>> schedule() to ensure watchdog's reset.
>> even if schedule performs other cyclic things (led blinking, card detect,
>> video_sync....).
>>
>> Recently schedule() has already been optimized (more precisely
>> cyclic_run()), currently i didn't see any
>> better optimization.
>
> The schedule() call should be effectively a no-op in case the next event is
> not yet due (whatever that next event is), so what does take so long in
> schedule() that it takes so long (70ms) to complete ?
>
Hi Marek
schedule() execution doesn't takes 70ms.
Moving schedule() from main loop to same level that ctrlc(), it allows to call
ctrlc() every ~70ms.
Patrice
