Message-ID: <1291248647.2846.34.camel@work-vm>
Date:	Wed, 01 Dec 2010 16:10:47 -0800
From:	john stultz <johnstul@...ibm.com>
To:	Jamie Lokier <jamie@...reable.org>
Cc:	Lennart Poettering <mzxreary@...inter.de>,
	Alexander Shishkin <virtuoso@...nd.org>,
	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Feng Tang <feng.tang@...el.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Michael Tokarev <mjt@....msk.ru>,
	Marcelo Tosatti <mtosatti@...hat.com>,
	Chris Friesen <chris.friesen@...band.com>,
	Kay Sievers <kay.sievers@...y.org>,
	"Kirill A. Shutemov" <kirill@...temov.name>,
	Artem Bityutskiy <dedekind1@...il.com>,
	Davide Libenzi <davidel@...ilserver.org>,
	linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH] [RFC] timerfd: add TFD_NOTIFY_CLOCK_SET to watch for
 clock changes

On Wed, 2010-12-01 at 10:43 +0000, Jamie Lokier wrote:
> Lennart Poettering wrote:
> > On Tue, 23.11.10 19:22, Alexander Shishkin (virtuoso@...nd.org) wrote:
> > 
> > > Certain userspace applications (like "clock" desktop applets or cron or
> > > systemd) might want to be notified when some other application changes
> > > the system time. There are several known to me reasons for this:
> > >  - avoiding periodic wakeups to poll time changes;
> > >  - rearming CLOCK_REALTIME timers when said changes happen;
> > >  - changing system timekeeping policy for system-wide time management
> > >    programs;
> > >  - keeping guest applications/operating systems running in emulators
> > >    up to date.
> > > 
> > > This is another attempt to approach notifying userspace about system
> > > clock changes. The other one is using an eventfd and a syscall [1]. In
> > > the course of discussing the necessity of a syscall for this kind of
> > > notifications, it was suggested that this functionality can be achieved
> > > via timers [2] (and timerfd in particular [3]). This idea got quite
> > > some support [4], [5], [6] and some vague criticism [7], so I decided
> > > to try and go a bit further with it.
> > 
> > I agree with Kay, this is pretty much exactly what we want for
> > systemd. (Assuming that the time jump due to system suspend is
> > propagated to userspace like any other time jump with this path).
> 
> I hope the time jump due to suspend is *not* propagated in the same
> way to userspace :-)

Sadly this behavior depends on architecture and rtc configuration.

For x86 and a number of other architectures, read_persisitent_clock()
functions and we inject the time in suspend into CLOCK_REALTIME on
resume. No notification would be seen.

For architectures where read_persistent_clock does not function (usually
due to RTC not being accessible with irqs are off), we rely on the RTC
code to set the time when it resumes and irqs are enabled. This happens
via do_settimeofday, so a notification would be seen.

A hook could be added so the non-read_persistent_clock supporting arches
can inject time into CLOCK_REALTIME without going through settimeofday()
and triggering the notification. But there may still be odd races around
other stuff running and getting the wrong time before the suspend time
is injected.

This ignores any userland resume scripts that may do something like call
ntpdate or whatever, which would call settimefoday().


> What I'd like to see:
> 
>  1. Time jump due to the system clock being stepped: Notification.
> 
>     This is *not* a change in real time.  It means the clock was
>     corrected/changed.  No physical time passed.

Right. That's settimeofday()/clock_settime().


>  2. Time jump due to suspend/resume: Different notification.
> 
>     This *is* a change in real time.  Physical time passed.

This is the case for read_persistent_clock() supported architectures.

Why do you want a notification here? Or is the resume hook enough?


>  3. Time drift corrections: As now, no notification, it's just
>     the clock being regulated.

Yep. adjtimex() handles this.


> To signal the difference between 1 and 2, there ought to be some way
> for userspace to determine how much of the clock delta corresponds
> with physical time, by reading some sort of "monotonic" clock :-)


Could you further expand on the needs for distinguishing between the
two?


> CLOCK_MONOTONIC is unsuitable because it stops at suspend.  Maybe it
> should stay that way.  But maybe not - programs using CLOCK_MONOTONIC
> usually want to trigger timeouts etc. based on real elapsed time, and
> after suspend/resume, it's quite reasonable to want to trigger all of
> a program's short timeouts immediately.  Indeed some network protocol
> userspace may currently behave *incorrectly* over suspend/resume,
> especially those using clock times to validate their caches,
> *because* CLOCK_MONOTONIC doesn't count it.

Is there a specific example of this occurring that you have in mind? 


> So maybe CLOCK_MONOTONIC should be changed to include elapsed time
> during suspend/resume, and CLOCK_MONOTONIC_RAW could remain as it is,
> for programs that want that?

No. Lets not change it. CLOCK_MONOTONIC and CLOCK_MONOTONIC_RAW's
relationship is tightly coupled, and applications that are tracking the
amount of clock adjustment being done to the system require they keep
their semantics.

As I said earlier, adding a new clockid to represent the MONOTONIC
+SUSPEND time wouldn't be difficult, we just need to be clear about why
it should be exposed, and have it also be easy to describe to developers
which clockid would suit their needs best.

thanks
-john


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists