From owner-freebsd-arch@FreeBSD.ORG Fri Nov 27 23:42:52 2009 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 C09B7106566B; Fri, 27 Nov 2009 23:42:52 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by mx1.freebsd.org (Postfix) with ESMTP id 06DA28FC13; Fri, 27 Nov 2009 23:42:51 +0000 (UTC) Received: by fxm10 with SMTP id 10so1711821fxm.14 for ; Fri, 27 Nov 2009 15:42:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=Wq48v7fmzzDIQzSlnDOCmbKM4qslUIBLa8EWscNUX1I=; b=gbw78aa8RiFvUuv+xi40sqhyLypcWc69GwsK0HfU+o8cWfpMHTl9b2iTeyFLibiCxo sLXmb3CI+bOeuvUuMTVy/2hYl2N+aCh2otMyJOC9mGbsyOfvYNeZy+AKw4Ysi6VifWfD 5jS5n/L3myzd7KfSiXitpT/T1S7AIHa+m56UQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=R4S1tlP7lf+G9pcLTEDmsYvLQfdLAdPFEV/urjJSh6ApwGHuYcruSugqGuMIz51jc9 iykrNXnaxRMr0Rj7O/UJw39ibbELUhdT3FJy4YbDedmtwbrhLPMqyQiHBk6PPB37F6pA wCGpf9Io7LFJCz2wXcl0Nz6FVEXHhQl8ENRNo= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.223.144.195 with SMTP id a3mr250837fav.103.1259365370823; Fri, 27 Nov 2009 15:42:50 -0800 (PST) Date: Sat, 28 Nov 2009 00:42:50 +0100 X-Google-Sender-Auth: c81e84e93859ad00 Message-ID: <3bbf2fe10911271542h2b179874qa0d9a4a7224dcb2f@mail.gmail.com> From: Attilio Rao To: FreeBSD Arch , John Baldwin , Ed Maste Content-Type: text/plain; charset=UTF-8 Cc: Subject: [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, 27 Nov 2009 23:42:52 -0000 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/statclock_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. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein