| Message ID | 1252081568-6000-2-git-send-email-mjg@redhat.com |
|---|---|
| State | Superseded, archived |
| Headers | show |
On Fri, 4 Sep 2009 12:26:08 -0400 Matthew Garrett <mjg@redhat.com> wrote: > CONFIG_RTC_HCTOSYS allows the kernel to read the system time from the RTC > at boot and resume, avoiding the need for userspace to do so. Unfortunately > userspace currently has no way to know whether this configuration option > is enabled and thus cannot sensibly choose whether to run hwclock itself or > not. Add a boot_timesource sysfs attribute which indicates whether a given > RTC set the system clock. This feature is meant to be in addition of the regular hwclock call to read the system time. Have you tested if there are drawbacks by not reading it? Like TZ, DST and similar?
On Fri, Sep 04, 2009 at 06:25:28PM +0200, Alessandro Zummo wrote: > This feature is meant to be in addition of the regular > hwclock call to read the system time. > > Have you tested if there are drawbacks by not reading it? Like > TZ, DST and similar? Current util-linux has a hwclock that can just set the timezone without performing a full read. However, there's no way of knowing whether it's safe to do this without knowing that the kernel config option was set and used. We'd prefer to avoid always doing --hctosys because it's a noticable performance hit on boot if the work's already been done by the kernel.
On Fri, 4 Sep 2009 17:30:29 +0100 Matthew Garrett <mjg59@srcf.ucam.org> wrote: > We'd prefer to avoid always doing --hctosys because it's a > noticable performance hit on boot if the work's already been done by the > kernel. it shouldn't. maybe your hwclock is waiting for the tick or something similar. I'd check it.
On Fri, Sep 04, 2009 at 06:38:28PM +0200, Alessandro Zummo wrote: > On Fri, 4 Sep 2009 17:30:29 +0100 > Matthew Garrett <mjg59@srcf.ucam.org> wrote: > > > We'd prefer to avoid always doing --hctosys because it's a > > noticable performance hit on boot if the work's already been done by the > > kernel. > > it shouldn't. maybe your hwclock is waiting for the tick > or something similar. I'd check it. I'm just going by what our userspace people are saying. They'd prefer not to have to run --hctosys if the time's already been set - https://bugzilla.redhat.com/show_bug.cgi?id=489494 has the discussion.
On Fri, 4 Sep 2009 17:41:27 +0100 Matthew Garrett <mjg59@srcf.ucam.org> wrote: > > it shouldn't. maybe your hwclock is waiting for the tick > > or something similar. I'd check it. > > I'm just going by what our userspace people are saying. They'd prefer > not to have to run --hctosys if the time's already been set - > https://bugzilla.redhat.com/show_bug.cgi?id=489494 has the discussion. > that's ok, but nonetheless there's a problem in hwclock if it takes 3 secs to read the time.
On Fri, Sep 04, 2009 at 06:52:43PM +0200, Alessandro Zummo wrote: > that's ok, but nonetheless there's a problem in hwclock > if it takes 3 secs to read the time. The 3-second case is with virtualised access to the cmos, but you're right that it does sound excessive. Even so, it seems like a win to be able to avoid running code that the kernel's already run
On Fri, 4 Sep 2009 17:55:49 +0100 Matthew Garrett <mjg59@srcf.ucam.org> wrote: > On Fri, Sep 04, 2009 at 06:52:43PM +0200, Alessandro Zummo wrote: > > > that's ok, but nonetheless there's a problem in hwclock > > if it takes 3 secs to read the time. > > The 3-second case is with virtualised access to the cmos, but you're > right that it does sound excessive. Even so, it seems like a win to be > able to avoid running code that the kernel's already run ok. I find boot_timesource to be not intuitive. I'd vote for hctosys or something like that.
On Fri, Sep 04, 2009 at 06:52:43PM +0200, Alessandro Zummo wrote: > > On Fri, 4 Sep 2009 17:41:27 +0100 > Matthew Garrett <mjg59@srcf.ucam.org> wrote: > > > > it shouldn't. maybe your hwclock is waiting for the tick > > > or something similar. I'd check it. > > > > I'm just going by what our userspace people are saying. They'd prefer > > not to have to run --hctosys if the time's already been set - > > https://bugzilla.redhat.com/show_bug.cgi?id=489494 has the discussion. > > > > that's ok, but nonetheless there's a problem in hwclock > if it takes 3 secs to read the time. IMHO 3 seconds is nonsense. It's usually 0.5 - 1 second. Anyway, the "hwclock --hctosys" in userspace is a mystical voodoo and it's definitely better to move this thing to kernel. Karel
diff --git a/Documentation/rtc.txt b/Documentation/rtc.txt index 216bb8c..a086cad 100644 --- a/Documentation/rtc.txt +++ b/Documentation/rtc.txt @@ -142,6 +142,8 @@ The sysfs interface under /sys/class/rtc/rtcN provides access to various rtc attributes without requiring the use of ioctls. All dates and times are in the RTC's timezone, rather than in system time. +boot_timesource: 1 if the RTC provided the system time at boot via the + CONFIG_RTC_HCTOSYS kernel option, 0 otherwise date: RTC-provided date max_user_freq: The maximum interrupt rate an unprivileged user may request from this RTC. diff --git a/drivers/rtc/rtc-sysfs.c b/drivers/rtc/rtc-sysfs.c index 2531ce4..dbd6af8 100644 --- a/drivers/rtc/rtc-sysfs.c +++ b/drivers/rtc/rtc-sysfs.c @@ -102,6 +102,19 @@ rtc_sysfs_set_max_user_freq(struct device *dev, struct device_attribute *attr, return n; } +static ssize_t +rtc_sysfs_show_hctosys(struct device *dev, struct device_attribute *attr, + char *buf) +{ +#ifdef CONFIG_RTC_HCTOSYS_DEVICE + if (strcmp(dev_name(&to_rtc_device(dev)->dev), + CONFIG_RTC_HCTOSYS_DEVICE) == 0) + return sprintf(buf, "1\n"); + else +#endif + return sprintf(buf, "0\n"); +} + static struct device_attribute rtc_attrs[] = { __ATTR(name, S_IRUGO, rtc_sysfs_show_name, NULL), __ATTR(date, S_IRUGO, rtc_sysfs_show_date, NULL), @@ -109,6 +122,7 @@ static struct device_attribute rtc_attrs[] = { __ATTR(since_epoch, S_IRUGO, rtc_sysfs_show_since_epoch, NULL), __ATTR(max_user_freq, S_IRUGO | S_IWUSR, rtc_sysfs_show_max_user_freq, rtc_sysfs_set_max_user_freq), + __ATTR(boot_timesource, S_IRUGO, rtc_sysfs_show_hctosys, NULL), { }, };
CONFIG_RTC_HCTOSYS allows the kernel to read the system time from the RTC at boot and resume, avoiding the need for userspace to do so. Unfortunately userspace currently has no way to know whether this configuration option is enabled and thus cannot sensibly choose whether to run hwclock itself or not. Add a boot_timesource sysfs attribute which indicates whether a given RTC set the system clock. Signed-off-by: Matthew Garrett <mjg@redhat.com> --- Documentation/rtc.txt | 2 ++ drivers/rtc/rtc-sysfs.c | 14 ++++++++++++++ 2 files changed, 16 insertions(+), 0 deletions(-)