Re: Timekeeping issue on aggressive suspend/resume

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

 



On Wed, Jun 9, 2010 at 1:22 PM, Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:
> Though we could change that conditionally - the default would still be
> the freeze of jiffies and CLOCK_MONOTONIC for historical compability.

If I were to change it only for our implementation, and make all the
user space timers use CLOCK_REALTIME, then could you please point me
in a direction as to what part of the kernel I should be touching to
make that change?

Earlier we faced issue with time that the application sees. It wasn't
getting updated when we suspend and resume the system (where as the
time inside the kernel kept updating) and hence eventually would drift
from the actual time.

for eg, if I use this loop at the command prompt

while date
do
echo mem > /sys/power/state
done

then the date command always displayed the same time, but the prints
from the kernel (I was using the printk time information) was
advancing as expected.

I found a patch at
https://patchwork.kernel.org/patch/50070/

Though this fixed the application time update issue, there are lot of
timers in the application which is still not working right.

Could anyone please point in some direction to find the solution?

Thanks,
Suresh
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux