Re: [PATCH v2 00/15] timers: Cleanup delay/sleep related mess

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Christophe JAILLET <christophe.jaillet@xxxxxxxxxx> writes:

> Le 16/09/2024 à 22:20, Christophe JAILLET a écrit :
>> Le 11/09/2024 à 07:13, Anna-Maria Behnsen a écrit :
>>> Hi,
>>>
>>> a question about which sleeping function should be used in 
>>> acpi_os_sleep()
>>> started a discussion and examination about the existing documentation and
>>> implementation of functions which insert a sleep/delay.
>>>
>>> The result of the discussion was, that the documentation is outdated and
>>> the implemented fsleep() reflects the outdated documentation but doesn't
>>> help to reflect reality which in turns leads to the queue which covers 
>>> the
>>> following things:
>>>
>>> - Split out all timeout and sleep related functions from hrtimer.c and 
>>> timer.c
>>>    into a separate file
>>>
>>> - Update function descriptions of sleep related functions
>>>
>>> - Change fsleep() to reflect reality
>>>
>>> - Rework all comments or users which obviously rely on the outdated
>>>    documentation as they reference "Documentation/timers/timers- 
>>> howto.rst"
>>>
>>> - Last but not least (as there are no more references): Update the 
>>> outdated
>>>    documentation and move it into a file with a self explaining file name
>>>
>>> The queue is available here and applies on top of tip/timers/core:
>>>
>>>    git://git.kernel.org/pub/scm/linux/kernel/git/anna-maria/linux- 
>>> devel.git timers/misc
>>>
>>> Signed-off-by: Anna-Maria Behnsen <anna-maria@xxxxxxxxxxxxx>
>> 
>> Hi,
>> 
>> not directly related to your serie, but some time ago I sent a patch to 
>> micro-optimize Optimize usleep_range(). (See [1])
>> 
>> The idea is that the 2 parameters of usleep_range() are usually 
>> constants and some code reordering could easily let the compiler compute 
>> a few things at compilation time.
>> 
>> There was consensus on the value of the change (see [2]), but as you are 
>
> Typo: there was *no* consensus...
>
>> touching things here, maybe it makes sense now to save a few cycles at 
>> runtime and a few bytes of code?
>> 

Sorry for the late reply. I'll check it and will come back to you.

Thanks,
	Anna-Maria






[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux