On 02/11/15 22:13, Anton Ivanov wrote:
> On 02/11/15 21:50, Richard Weinberger wrote:
>> Am 02.11.2015 um 17:16 schrieb Anton Ivanov:
>>> -void idle_sleep(unsigned long long nsecs)
>>> +/**
>>> + * os_idle_sleep() - sleep for a given time of nsecs
>>> + * @nsecs: nanoseconds to sleep
>>> + */
>>> +void os_idle_sleep(unsigned long long nsecs)
>>> {
>>> struct timespec ts;
>>>
>>> - /*
>>> - * nsecs can come in as zero, in which case, this starts a
>>> - * busy loop. To prevent this, reset nsecs to the tick
>>> - * interval if it is zero.
>>> - */
>>> - if (nsecs == 0)
>>> - nsecs = UM_NSEC_PER_SEC / UM_HZ;
>>> + if (nsecs <= 0) {
>>> + return;
>>> + }
>>>
>>> - nsecs = sleep_time(nsecs);
>>> - ts = ((struct timespec) { .tv_sec = nsecs / UM_NSEC_PER_SEC,
>>> - .tv_nsec = nsecs % UM_NSEC_PER_SEC });
>>> + ts = ((struct timespec) {
>>> + .tv_sec = nsecs / UM_NSEC_PER_SEC,
>>> + .tv_nsec = nsecs % UM_NSEC_PER_SEC
>>> + });
>>>
>>> - if (nanosleep(&ts, &ts) == 0)
>>> + if (clock_nanosleep(CLOCK_MONOTONIC, 0, &ts, NULL)) {
>>> deliver_alarm();
>>> - after_sleep_interval(&ts);
>>> + }
>> Hmm, now this function sleeps at most nsecs. If it is interrupted
>> the alarm is delivered.
>> Why only upon interruption and not also if clock_nanosleep()
>> completes?
> It is invoked differently.
>
> We changed process.c too.
>
> The old behaviour used to be to disable the timer, read timer remaining
> and program a nanosleep with that. This resulted in the timer actually
> firing in idle despite UML using the virtual clock for timers.
>
> With timer moving to MONOTONIC we could do the same, but we do not need
> to. Instead of disabling the timer we can leave it running and program a
> nanosleep which is long enough in most cases for the timer to fire. This
> is what the matching change in process.c does. Together, this results in
> saving at least 2 syscalls per each idle invocation.
Re-reading this, I did not answer the question fully, apologies.
clock_nanosleep here is usually programmed with a fixed value in
process.c which is of no relation to the time when the next timer
interrupt should be delivered. So there is no need to re-deliver an
interrupt at the end of a nanosleep as the end of the nanosleep is of no
significance as far as the timer subsystem is concerned.
IMHO, the IRQ only needs to be relayed when the nanosleep is interrupted.
That differs to the old behaviour which programmed the nanosleep with
the remainder of the time till the next interrupt thus making it
necessary to relay once the nanosleep expires and restart the nanosleep
if it was interrupted by IO.
A.
>
> A.
>
>> Thanks,
>> //richard
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> User-mode-linux-devel mailing list
>> User-mode-linux-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
>>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> User-mode-linux-devel mailing list
> User-mode-linux-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
>
------------------------------------------------------------------------------
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
