Date: Mon, 30 Jul 2012 10:14:40 +0300 From: Alexander Motin <mav@FreeBSD.org> To: Bruce Evans <brde@optusnet.com.au> Cc: freebsd-acpi@FreeBSD.org Subject: Re: Using bintime() in acpi_cpu_idle()? Message-ID: <50163460.6070508@FreeBSD.org> In-Reply-To: <501628D2.2090507@FreeBSD.org> References: <5014DD00.3000307@FreeBSD.org> <20120729175031.U2084@besplex.bde.org> <50150CF5.4070605@FreeBSD.org> <20120729221526.H2941@besplex.bde.org> <50154C58.4060408@FreeBSD.org> <20120730141426.D1219@besplex.bde.org> <501628D2.2090507@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 30.07.2012 09:25, Alexander Motin wrote: > On 30.07.2012 07:33, Bruce Evans wrote: >> On Sun, 29 Jul 2012, Alexander Motin wrote: >> >>> On 29.07.2012 15:26, Bruce Evans wrote: >>>> On Sun, 29 Jul 2012, Alexander Motin wrote: >>>> >>>>> On 29.07.2012 11:37, Bruce Evans wrote: >>>>> ... >>>>>> binuptime() is more accurate than uncalibrated scaling. Is accuracy >>>>>> required? >>>>> >>>>> Accuracy is not required at all. +-20% is not a problem. >>>>> >>>>>> If not, the CPU ticker might work, and is faster than HPET, >>>>>> and and is not under user control for perverse settings. It normally >>>>>> reduces to readtsc() with no serializing instruction even in proposed >>>>>> changes. This is good enough for process times (not very good) and >>>>>> depends on the CPU not changing. Its calibration is very accurate >>>>>> (similar to timecounters) modulo bugs, but not always up to date. >>>>> >>>>> Problem with ticker that it may stop during idle periods, and idle is >>>>> exactly what happens here. Unlike timecounter usage here we don't need >>>>> CPU synchronicity, but we need it working during deep sleeps. >>>> >>>> The ticker is the same as the timecounter in many cases of >>>> interest. If >>>> the TSC stops then it cannot be used for timecounting unless >>>> timecounting >>>> is reinitialized. Timecounting should be reinitialized after deep >>>> sleeps, >>>> but you say you need it to work during deep sleeps. >>> >>> Timecounter already has detection logic to disable TSC in cases where >>> it is unreliable. I don't want to replicate it here. I need not >>> precise and not synchronized by reliable and fast time source. >> >> Yes, this logic gives exactly what you don't want (an inefficient >> timecounter), by preventing use of the TSC for the timecounter, although >> the TSC is perfectly usable for the ticker and here. > > Can you teach me how to use ticker that is not ticking? If TSC was > considered unusable for timecounter for reasons unrelated to SMP, how > can I use it as ticker. > >>>> I wouldn't trust timecounters for some time after waking up after a >>>> deep sleep. If their clock stopped then the times read might only be >>>> very out of date. If their clock didn't stop, then they might have >>>> wrapped or otherwise overflowed and the times read would be garbage. >>>> Is there any locking or ordering to prevent them being used before they >>>> are reinitialized? >>> >>> I am not sure what reinitialization are you talking about. IIRC, there >>> is no any waking up code for TSC. None other time counters have >>> problems with C-states. >> >> It is the timecounter code that needs reinitializing. If the TSC stops, >> or wraps mod 2**32, then its counts become garbage for the purpose of >> timecounting. Maybe it is not used for timecounting in either of these >> cases. But these cases shouldn't prevent its use for timecounting. >> >> The 2**32 number is because timecounters only use 32 bits of hardware >> counters (for efficiency). So even if the hardware has some magic to >> not stop the TSC while sleeping (maybe it fakes not stopping it be >> reloading on wakeup), it is still unusable by timecounters after sleeping >> for a second or 2 so that it wraps. The software needs similar faking >> to reload the timecounter on wakeup. This makes use of timecounters in >> sleep/wakeup code fragile. > > At this moment I am not talking about S-states sleeping for hours. I am > talking about C-states for milliseconds. It means that TSC may stop and > start 10K times each second or even more. Attempt to save and restore > its state will consume so much resources, that probably make it useless. > > What's about wrap after 2 seconds, I would be happy to make CPU sleep > for so long, but now 100ms is all I can hope even on idle system. > >> At boot time there is a dummy timecounter that returns bogo-times. >> Apparently sleeping doesn't occur before the timecounter is switched to >> a real one. The dummy timecounter isn't switched back to after boot >> time. But it probably should be, since the hardware timecounter may >> have stopped or wrapped. Sleeping could just set a flag to indicate >> this state, but then you would have to provide a fake time anyway on >> finding the flag set. Boot time just points to the dummy timecounter >> so as not to check this flag in all early timecounter "hardware" calls. > > And how dummy timecounter that counts something, but not time, can help > me to measure sleep time? Nevermind, let it be compromise solution -- ticker for C1 state where performance is the most important and where TSC works and ACPI timer for others. -- Alexander Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50163460.6070508>