[PATCH v2] usb: gadget: f_mass_storage: Move schedule() in sleep_thread()

[Patrice CHOTARD]

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