Date: Mon, 30 Jul 2012 09:25:22 +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: <501628D2.2090507@FreeBSD.org> In-Reply-To: <20120730141426.D1219@besplex.bde.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>
next in thread | previous in thread | raw e-mail | index | archive | help
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? -- Alexander Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?501628D2.2090507>