[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.00.1103101004540.2787@localhost6.localdomain6>
Date: Thu, 10 Mar 2011 10:08:18 +0100 (CET)
From: Thomas Gleixner <tglx@...utronix.de>
To: Kay Sievers <kay.sievers@...y.org>
cc: Andrew Morton <akpm@...ux-foundation.org>,
Alexander Shishkin <virtuoso@...nd.org>,
linux-kernel@...r.kernel.org, Ken MacLeod <ken@...sko.slc.ut.us>,
Shaun Reich <predator106@...il.com>,
Alexander Viro <viro@...iv.linux.org.uk>,
Greg Kroah-Hartman <gregkh@...e.de>,
Feng Tang <feng.tang@...el.com>,
Michael Tokarev <mjt@....msk.ru>,
Marcelo Tosatti <mtosatti@...hat.com>,
John Stultz <johnstul@...ibm.com>,
Chris Friesen <chris.friesen@...band.com>,
"Kirill A. Shutemov" <kirill@...temov.name>,
Artem Bityutskiy <dedekind1@...il.com>,
Davide Libenzi <davidel@...ilserver.org>,
linux-fsdevel@...r.kernel.org, linux-api@...r.kernel.org,
Michael Kerrisk <mtk.manpages@...il.com>
Subject: Re: [RFCv4] timerfd: add TFD_NOTIFY_CLOCK_SET to watch for clock
changes
On Thu, 10 Mar 2011, Kay Sievers wrote:
> On Thu, Mar 10, 2011 at 01:25, Andrew Morton <akpm@...ux-foundation.org> wrote:
> > On Wed, 9 Mar 2011 16:36:51 +0200
> > Alexander Shishkin <virtuoso@...nd.org> wrote:
> >
> >> Changes since v3:
> >> - changed timerfd_settime() semantics (see below)
> >> Changes since v2:
> >> - replaced sysfs interface with a syscall
> >> - added sysctl/procfs handle to set a limit to the number of users
> >> - fixed issues pointed out by Greg.
> >> Changes since v1:
> >> - updated against 2.6.36-rc1,
> >> - added notification/filtering options,
> >> - added Documentation/ABI/sysfs-kernel-time-notify interface description.
>
> > It would be helpful to know if the identified users of this feature
> > actually find it useful and adequate. I guess the most common
> > application is the 1,001 desktop clock widgets. Do you have any
> > feedback from any of the owners of those?
>
> We want it for systemd, to provide cron-like functionality but without
> the need to stupidly wake up every minute and check the system time
> for possible jumps.
>
> It also sounds useful for a generic resume (after system suspend)
> notification for applications, which isn't really possible today.
Note, that we have CLOCK_BOOTTIME pending for .39 which aims at the
same problem. It's basically CLOCK_MONOTONIC adjusted by the time we
were in suspend. So while CLOCK_MONOTONIC timers are not aware of the
time spent in suspend CLOCK_BOOTTIME timers are. The reason for
implementing CLOCK_BOOTTIME was basically the same problem.
Thanks,
tglx
Powered by blists - more mailing lists