From owner-freebsd-performance@FreeBSD.ORG Tue Jul 27 18:44:55 2010 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A1B311065670; Tue, 27 Jul 2010 18:44:55 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id CD8508FC14; Tue, 27 Jul 2010 18:44:54 +0000 (UTC) Received: by fxm13 with SMTP id 13so861548fxm.13 for ; Tue, 27 Jul 2010 11:44:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=vwM3oOzazoVICoeBt30W6FdEX3ICVIxGQZyUCLrVI0s=; b=sJjGMhgZ2zl2L2B9nJke024C3vz8RdA/UNuw/0cSYa6DriYn8dta2NbRAX7HbVqBSh vH3B+ssWSVnJqS2879EkFJAQRcl6k4WAUWDZllHAuED4K+QItYATR/2jliLHnQpIEAZB FzG3/qUglHSZDf0Cvo8S8Ctd2WB43gAD+HcAQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=nvvJGTqd0X9Ud9x+5Dk85V33PEoy6uH+ZKrflOrBCZIVXXyUHv4kxktIIsxpKdnMD/ 71Ef19verD6Kt3PCYIoQyoOLZ8ELA9PzkmN1BAQ1A/ZeBQ5XTqfGEkrHFrC/Gyjt5hld u+m7kxyZqrmimtW6nc2dcVUevpDYJiF2EA+Oc= Received: by 10.223.119.131 with SMTP id z3mr8524223faq.61.1280256293689; Tue, 27 Jul 2010 11:44:53 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id e22sm1418129faa.0.2010.07.27.11.44.52 (version=SSLv3 cipher=RC4-MD5); Tue, 27 Jul 2010 11:44:52 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C4F2921.5030604@FreeBSD.org> Date: Tue, 27 Jul 2010 21:44:49 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: alc@freebsd.org References: <4C4AF046.40507@FreeBSD.org> <4C4B720A.6020802@FreeBSD.org> <4C4D9779.8080505@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 27 Jul 2010 18:54:12 +0000 Cc: freebsd-hackers@freebsd.org, freebsd-performance@freebsd.org Subject: Re: Intel TurboBoost in practice X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2010 18:44:55 -0000 Alan Cox wrote: > On Mon, Jul 26, 2010 at 9:11 AM, Alexander Motin > 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