From owner-freebsd-arch@FreeBSD.ORG Fri Jan 15 15:06:14 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF7F01065679; Fri, 15 Jan 2010 15:06:14 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by mx1.freebsd.org (Postfix) with ESMTP id 57FAC8FC0C; Fri, 15 Jan 2010 15:06:14 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 5so39963qwd.7 for ; Fri, 15 Jan 2010 07:06:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=oLtabJzhVmQzneyS+NEzPe0L71tzjT0ZmfhCIyS65M0=; b=FIX0rBe61HBGoB0wF88WJhnIR3oU/Hti1rP1wGNe2EigmKA7FTS4AuvCK0nW19mOAo 2sckCmbgPSCPJNKBIJnnxonSjNSqbqkMp77GPrpdIMoT2kCUwY3KZ0K4wMA1dJI5ZST8 njwRf41+TApZfn2mSpo1Ahjs7ROPTWdwhXWdY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=KyzNv22/zC+7W+XseaFp65ZmocPbTkKhf3dTxTi73KJNwRnJ57gLKPMtHkmYcvh24W TZHj3vi19Bj7c1h5BvlJs1auZ78ezF1K1OrHfd71ZCQOgLkaANaUBO4BgePMHJ3lPxAy uTsvpLxNLbUYjlVujR9nkhOct0YQpu/61HPCs= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.102.17.28 with SMTP id 28mr1119720muq.120.1263567965020; Fri, 15 Jan 2010 07:06:05 -0800 (PST) In-Reply-To: <200911301305.30572.jhb@freebsd.org> References: <3bbf2fe10911271542h2b179874qa0d9a4a7224dcb2f@mail.gmail.com> <200911301305.30572.jhb@freebsd.org> Date: Fri, 15 Jan 2010 10:06:04 -0500 X-Google-Sender-Auth: b938bcab5359cbd5 Message-ID: <3bbf2fe11001150706y765159a2jbd37c7ae4cf378f0@mail.gmail.com> From: Attilio Rao To: John Baldwin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Arch , Ed Maste Subject: Re: [PATCH] Statclock aliasing by LAPIC X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2010 15:06:15 -0000 2009/11/30 John Baldwin : > On Friday 27 November 2009 6:42:50 pm Attilio Rao wrote: >> Handling all the three clocks (hardclock, softclock, profclock) within >> the LAPIC can lead to aliasing for the softclock and profclock because >> hz is sized to fit mainly hardclock. The fashion to handle all of them >> within the LAPIC was introduced in 2005 and before than the softclock >> and profclock were supposed to be handled in the rtc. Right now, too, >> there is the necessary support to handle profclock and statclock in >> atrtc which gets enabled if the LAPIC signals it can't take in charge >> the three clocks. >> The proposed patch reverts the situation preferring the atrtc to >> handle the statclock and profclock (then a different source from the >> LAPIC) and then avoid the aliasing problem: >> > http://www.freebsd.org/~attilio/Sandvine/STABLE_8/statclock_aliasing/stat= clock_aliasing3.diff >> >> In this patch, lapic_setup_clock() has been changed in order to return >> a three-states variable which identified if the LAPIC got in charge >> all the three clocks, just the hardclock or none of them (the current >> situation is just none/all) and the rtc handling runs subsequently. >> A tunable as been added to force LAPI to get in charge all the three >> clocks if needed. >> In ia32 atrtc compiling is linked to atpic compiling, so a compile >> time flag has been added to check if atpic is not present and in case >> force LAPIC to take in charge all the three clocks (which is still >> better than the 'safe belt values' still present in the rtc code). >> >> Please note that statclock and profclock are widely used in our kernel >> (rusage is, for example, statclock driven) and fixing this would >> result in specific improvements (as a several-reported wrong CPU usage >> statistic in top). >> This bug has been found by Sandvine Incorporated. >> >> Reviews, comments and testing are welcome. > > Presumably in the RTC case lapic_timer_hz should always be hz and not som= e > multiple of hz. =C2=A0Also, did you check to make sure all the lock is pr= esent? =C2=A0I > think at one point I changed the locking for the RTC and/or ISA timer to = just > use critical_enter/exit so that UP machines running an SMP kernel wouldn'= t pay > the locking overhead since the code was only used on UP machines. =C2=A0I= t may very > well be that I only changed that in a development branch though and not i= n > HEAD. I still see clock_lock in place (and no particular critical section code in that paths) or you meant to say that the clock_lock doesn't still provide enough protection alone? BTW, you were right about the lapic_timer_hz (I forgot to revert to hz). There is an updated patch: http://www.freebsd.org/~attilio/Sandvine/STABLE_8/statclock_aliasing/statcl= ock_aliasing4.diff Thanks, Attilio --=20 Peace can only be achieved by understanding - A. Einstein