[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20101112123044.GD10585@shisha.kicks-ass.net>
Date: Fri, 12 Nov 2010 14:30:44 +0200
From: Alexander Shishkin <virtuoso@...nd.org>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: Valdis.Kletnieks@...edu, linux-kernel@...r.kernel.org,
John Stultz <johnstul@...ibm.com>,
Andrew Morton <akpm@...ux-foundation.org>,
"H. Peter Anvin" <hpa@...or.com>,
Kay Sievers <kay.sievers@...y.org>, Greg KH <gregkh@...e.de>,
Chris Friesen <chris.friesen@...band.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
"Kirill A. Shutemov" <kirill@...temov.name>
Subject: Re: [PATCHv6 0/7] system time changes notification
On Thu, Nov 11, 2010 at 10:16:03PM +0100, Thomas Gleixner wrote:
> B1;2401;0cOn Thu, 11 Nov 2010, Alexander Shishkin wrote:
>
> > On Thu, Nov 11, 2010 at 03:28:13PM -0500, Valdis.Kletnieks@...edu wrote:
> > > On Thu, 11 Nov 2010 21:29:55 +0200, Alexander Shishkin said:
> > >
> > > > Consider we want stuff like "wakeup every day at 3pm", the next wakeup
> > > > might be earlier than the timer we calculated last time, on system
> > > > time changes. We need to re-calculate it. This is necessary for all
> > > > repeating events.
> > > >
> > > > Say we want to wakeup at 3pm, now it's 4pm, so we schedule it in 23
> > > > hours. Now the system time changes to 2pm, and we would expect to
> > > > wakeup in one hour, but we take 25.
> > >
> > > Sorry, I tuned in late here...
> > >
> > > So the plan is that if you're not using this new interface, it will go off at
> > > the same absolute offset (23 hours after timer was set), but if you're using
> > > this interface, your timer event gets interrupted, you get woken up (say)
> > > 15 hours into your 23, and it's your job to decide if you need to set a
> > > new timer for the remaining 6, 7, 8 hours or some other number?
> >
> > Yes. This interface doesn't deal with timers, it only provides notifications.
>
> The notification itself is pointless unless your application is
> dealing with timers which need to be adjusted the one way or the
> other.
Not quite. There are two use cases that I know of that need this notification
but don't use timers like that. One was described by Chris Friesen in the
comments to the first version of this patchset [1]. The other one was
described by me in the same thread [2]. They could, of course start using
timers specifically to get this notification, but I'm not sure if it doesn't
abuse the whole idea of timers.
> That said, I'm still not convinced that this usecase justifies a new
> systemcall.
Well, initially it was a sysfs interface (an arguably ugly one, though).
> 1) We can make timers wake up when a clock change happens
Isn't there a race so that if two clock changes happen in quick succession,
the user might lose the second one while he restarts the timer?
> 2) Can't we use existing notification stuff like uevents or such ?
I thought about that in the beginning but uevents indeed seem too heavy
for this sort of notification, especially compared to eventfds.
[1] http://lkml.org/lkml/2010/8/4/383
[2] http://lkml.org/lkml/2010/8/5/192
Regards,
--
Alex
--
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