Date: Sat, 21 Mar 2015 20:42:38 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Mike Tancsa <mike@sentex.net> Cc: FreeBSD-STABLE Mailing List <freebsd-stable@FreeBSD.org>, John-Mark Gurney <jmg@funkthat.com>, d@delphij.net, jkim@freebsd.org, John Baldwin <jhb@FreeBSD.org> Subject: Re: RELENG_10 performance regression (was Re: 35-40% performance drop releng9 vs releng10 openvpn Message-ID: <20150321184238.GO2379@kib.kiev.ua> In-Reply-To: <550DB4B2.7080603@sentex.net> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT> > Features2=0x802209<SSE3,MON,SSSE3,CX16,POPCNT> > AMD Features=0x2e500800<SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM> > AMD > Features2=0x35ff<LAHF,CMP,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,IBS,SKINIT,WDT> > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150321184238.GO2379>