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.

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

Reply via email to