From owner-freebsd-stable@FreeBSD.ORG Sat Mar 21 18:42:55 2015 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 90791E21; Sat, 21 Mar 2015 18:42:55 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 32D6F9FA; Sat, 21 Mar 2015 18:42:55 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t2LIgcHV091718 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 21 Mar 2015 20:42:39 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t2LIgcHV091718 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t2LIgcus091717; Sat, 21 Mar 2015 20:42:38 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 21 Mar 2015 20:42:38 +0200 From: Konstantin Belousov To: Mike Tancsa Subject: Re: RELENG_10 performance regression (was Re: 35-40% performance drop releng9 vs releng10 openvpn Message-ID: <20150321184238.GO2379@kib.kiev.ua> References: <5509D6C6.4050204@sentex.net> <20150318211457.GL51048@funkthat.com> <550B6950.8060806@sentex.net> <550C5AAF.9060502@sentex.net> <550C8AEE.4090408@sentex.net> <550CB306.7030405@delphij.net> <20150321001559.GB2379@kib.kiev.ua> <550CBF80.6030809@sentex.net> <550D93C7.9080709@FreeBSD.org> <550DB4B2.7080603@sentex.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <550DB4B2.7080603@sentex.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: FreeBSD-STABLE Mailing List , John-Mark Gurney , d@delphij.net, jkim@freebsd.org, John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 18:42:55 -0000 On Sat, Mar 21, 2015 at 02:13:06PM -0400, Mike Tancsa wrote: > On 3/21/2015 11:52 AM, John Baldwin wrote: > > >> http://tancsa.com/time/ > > > > Do you know why you are using the HPET instead of TSC for timestamping? > > Hi, > > I am not consciously making any time keep decisions. > > kern.eventtimer.choice: HPET(550) HPET1(450) LAPIC(400) i8254(100) RTC(0) > kern.timecounter.choice: TSC(800) HPET(950) ACPI-fast(900) i8254(0) > dummy(-1000000) > > (The full hardware info is at the above url) > > > > Using the TSC can make a non-trivial performance difference since userland > > can calculate timestamps without using system calls when it is used. > > (That is not related to this case, but switching to the TSC in general is > > preferable.) > > > > There are a few generations of Intel CPUs where you can't mix deeper sleep > > states with the TSC as timecounter, but those CPUs are getting to be a bit > > older at this point. > > > > This one is an AMD > CPU: AMD G-T40E Processor (1000.02-MHz K8-class CPU) > Origin="AuthenticAMD" Id=0x500f20 Family=0x14 Model=0x2 Stepping=0 > > Features=0x178bfbff > Features2=0x802209 > AMD Features=0x2e500800 > AMD > Features2=0x35ff > SVM: NP,NRIP,NAsids=8 > TSC: P-state invariant, performance statistics It seems to be a consequnce of the code from r222869. The test_tsc() does not trust the P-state invariant report and explicitely check for the family. Your CPU family is 0x14, while code only bumps TSC priority for family 0x15+. Currently, tsc_is_invariant is set when CPU reports AMDPM_TSC_INVARIANT, or for some models. Should we bump TSC timecounter priority is smp test passed and AMDPM_TSC_INVARIANT is set ? For now, you could just set TSC as timecounter.