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

On 8/17/26 5:29 PM, Patrice CHOTARD wrote:
> 
> 
> On 8/16/26 21:03, Marek Vasut wrote:
>> On 8/6/26 9:27 AM, Patrice CHOTARD wrote:
>>>
>>>
>>> On 8/6/26 02:33, Marek Vasut wrote:
>>>> On 8/5/26 9:30 AM, Patrice CHOTARD wrote:
>>>>
>>>> Hello Patrice,
>>>>
>>>>>> 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
>>>>>>
>>>>> Hi Marek
>>>>>
>>>>> Is it OK for you to merge this patch ?
>>>> Is this series still necessary with the cyclic fixes in place ?
>>>
>>> Yes it allows to get an additional reactivity gain.
>>>
>>> With the cyclic fixes 9c1b13b3fd27 ("cyclic: reduce get_timer_us() calls inside hlist_for_each_entry_safe()")
>>> ctrlc() is called every ~280ms
>>>
>>> With this patch, ctrlc() is called every ~70ms.
>> Is there any chance we can optimize the schedule() call further instead?
> 
> Hi Marek
> 
> 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.