Date: Tue, 27 Jul 2010 21:44:49 +0300 From: Alexander Motin <mav@FreeBSD.org> To: alc@freebsd.org Cc: freebsd-hackers@freebsd.org, freebsd-performance@freebsd.org Subject: Re: Intel TurboBoost in practice Message-ID: <4C4F2921.5030604@FreeBSD.org> In-Reply-To: <AANLkTi=G6wGSnsX-61ipcQqgsHpdWLR-1N%2BRybbpoR7Z@mail.gmail.com> References: <4C4AF046.40507@FreeBSD.org> <A30A636F-E925-456E-8866-4E46B3BA367F@lavabit.com> <4C4B720A.6020802@FreeBSD.org> <alpine.BSF.2.00.1007261318380.10170@fledge.watson.org> <4C4D9779.8080505@FreeBSD.org> <AANLkTi=G6wGSnsX-61ipcQqgsHpdWLR-1N%2BRybbpoR7Z@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Alan Cox wrote: > On Mon, Jul 26, 2010 at 9:11 AM, Alexander Motin <mav@freebsd.org > <mailto:mav@freebsd.org>> wrote: > > In that case using C2 or C3 predictably caused small performance reduce, > as after falling to sleep, CPU needs time to wakeup. Even if tested CPU0 > won't ever sleep during test, it's TLB shutdown IPIs to other cores > still probably could suffer from waiting other cores' wakeup. > > In the deeper sleep states, are the TLB contents actually maintained > while the processor sleeps? (I notice that in some configurations, we > actually flush dirty data from the cache before sleeping.) As I understand, we flush caches only as last resort, if platform does not supports special techniques, such as disabling arbitration or making CPU to wake up on bus mastering. But same ACPI C-states could map into different CPU C-states. Some of these CPU states (like C6) could imply caches invalidation, though I am not sure it can be seen outside. ACPI 3.0 specification tells nothing about TLBs, so I am not sure we can count on their invalidation, except we do it ourselves, like it is done for caches when CPU can't keep their coherency while sleeping. -- Alexander Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C4F2921.5030604>