On 04/01/2013 01:31 PM, Pavel Machek wrote:
Certainly for short sleeps. Is TSC actually precise enough to keep
precise time for hours? I thought TSC sucked at precision.
Well, we can measure suspend using the ntp corrected frequency, so that
should be ok, assuming the freq doesn't change duri
Hi!
> >>>On some new Intel Atom processors (Penwell and Cloverview), there is
> >>>a feature that the TSC won't stop S3, say the TSC value won't be
> >>>reset to 0 after resume. This feature makes TSC a more reliable
> >>>clocksource and could benefit the timekeeping code during system
> >>>suspen
On 03/30/2013 11:14 AM, Pavel Machek wrote:
Hi!
On some new Intel Atom processors (Penwell and Cloverview), there is
a feature that the TSC won't stop S3, say the TSC value won't be
reset to 0 after resume. This feature makes TSC a more reliable
clocksource and could benefit the timekeeping cod
Hi!
> >On some new Intel Atom processors (Penwell and Cloverview), there is
> >a feature that the TSC won't stop S3, say the TSC value won't be
> >reset to 0 after resume. This feature makes TSC a more reliable
> >clocksource and could benefit the timekeeping code during system
> >suspend/resume c
On Thu, Jan 24, 2013 at 11:37:30AM +0800, Feng Tang wrote:
> > I think hard numbers would be needed to show the rtc layer is
> > causing major issues for space constrained kernels, so this
> > trade-off could be properly prioritized. Having duplicate code paths
> > in standard kernels is wasteful
On Tue, Jan 22, 2013 at 01:56:09PM -0800, John Stultz wrote:
> On 01/22/2013 06:55 AM, Feng Tang wrote:
> >Hi John,
> >
> >On Mon, Jan 21, 2013 at 10:46:31AM -0800, John Stultz wrote:
> >>What I'd propose is that we break the read_persistent_clock()
> >>functionality up. So we need two interfaces:
On Tue, Jan 22, 2013 at 07:07:04PM -0800, John Stultz wrote:
> But personally, I'm less fond of adding additional state to the
> clocksources, as I'm (admittedly, very) slowly trying to go the
> other way, and make the clocksources mostly state free. This is in
> part to allow for faster timekeepi
On 01/22/2013 06:35 PM, Jason Gunthorpe wrote:
On Tue, Jan 22, 2013 at 05:54:21PM -0800, John Stultz wrote:
complicated part. Additionally, there may be cases where the
timekeeping clocksource is one clocksource and the suspend
clocksource is another. So I think to properly integrate this sort
On Tue, Jan 22, 2013 at 05:54:21PM -0800, John Stultz wrote:
> >>complicated part. Additionally, there may be cases where the
> >>timekeeping clocksource is one clocksource and the suspend
> >>clocksource is another. So I think to properly integrate this sort
> >Does the difference matter? The clo
On 01/22/2013 05:37 PM, Jason Gunthorpe wrote:
On Tue, Jan 22, 2013 at 04:41:58PM -0800, John Stultz wrote:
Right but to calculate an suspend interval (since they are likely
many orders of magnitude larger then the intervals between timer
interrupts), you need different mult/shift selection. I
On Tue, Jan 22, 2013 at 04:41:58PM -0800, John Stultz wrote:
> Right but to calculate an suspend interval (since they are likely
> many orders of magnitude larger then the intervals between timer
> interrupts), you need different mult/shift selection. Its splitting
> out the mult/shift management
On 01/22/2013 04:26 PM, Jason Gunthorpe wrote:
On Tue, Jan 22, 2013 at 12:22:29PM -0800, John Stultz wrote:
How big of an issue is this? Could the RTCTOSYS function be moved to
the moment the RTC driver is registered rather than using a
late_initcall?
It may not be huge. Most early boot items
On Tue, Jan 22, 2013 at 12:22:29PM -0800, John Stultz wrote:
> >How big of an issue is this? Could the RTCTOSYS function be moved to
> >the moment the RTC driver is registered rather than using a
> >late_initcall?
>
> It may not be huge. Most early boot items are going to be
> CLOCK_MONOTONIC bas
On 01/22/2013 06:55 AM, Feng Tang wrote:
Hi John,
On Mon, Jan 21, 2013 at 10:46:31AM -0800, John Stultz wrote:
What I'd propose is that we break the read_persistent_clock()
functionality up. So we need two interfaces:
1) An interface to access a time value we used to initialize the
system's CLO
On 01/22/2013 11:57 AM, Jason Gunthorpe wrote:
On Mon, Jan 21, 2013 at 10:46:31AM -0800, John Stultz wrote:
What I'd propose is that we break the read_persistent_clock()
functionality up. So we need two interfaces:
1) An interface to access a time value we used to initialize the
system's CLOC
On Mon, Jan 21, 2013 at 10:46:31AM -0800, John Stultz wrote:
> What I'd propose is that we break the read_persistent_clock()
> functionality up. So we need two interfaces:
> 1) An interface to access a time value we used to initialize the
> system's CLOCK_REALTIME time.
> 2) An interface to measu
Hi John,
On Mon, Jan 21, 2013 at 10:46:31AM -0800, John Stultz wrote:
> On 01/20/2013 10:38 PM, Feng Tang wrote:
> >Hi All,
> >
> >On some new Intel Atom processors (Penwell and Cloverview), there is
> >a feature that the TSC won't stop S3, say the TSC value won't be
> >reset to 0 after resume. Th
On 01/20/2013 10:38 PM, Feng Tang wrote:
Hi All,
On some new Intel Atom processors (Penwell and Cloverview), there is
a feature that the TSC won't stop S3, say the TSC value won't be
reset to 0 after resume. This feature makes TSC a more reliable
clocksource and could benefit the timekeeping cod
On 1/21/2013 7:38 AM, Feng Tang wrote:
Hi All,
On some new Intel Atom processors (Penwell and Cloverview), there is
a feature that the TSC won't stop S3, say the TSC value won't be
reset to 0 after resume. This feature makes TSC a more reliable
clocksource and could benefit the timekeeping code
Hi All,
On some new Intel Atom processors (Penwell and Cloverview), there is
a feature that the TSC won't stop S3, say the TSC value won't be
reset to 0 after resume. This feature makes TSC a more reliable
clocksource and could benefit the timekeeping code during system
suspend/resume cycles.
The
20 matches
Mail list logo
