From owner-freebsd-arch@FreeBSD.ORG Tue Jan 19 19:16:43 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 C3E2B106566B; Tue, 19 Jan 2010 19:16:43 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7F13A8FC08; Tue, 19 Jan 2010 19:16:43 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id F2DF146B1A; Tue, 19 Jan 2010 14:16:42 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 2062A8A026; Tue, 19 Jan 2010 14:16:42 -0500 (EST) From: John Baldwin To: Attilio Rao Date: Tue, 19 Jan 2010 13:40:31 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20091231; KDE/4.3.1; amd64; ; ) References: <3bbf2fe10911271542h2b179874qa0d9a4a7224dcb2f@mail.gmail.com> <201001191144.23299.jhb@freebsd.org> <3bbf2fe11001190927m10f73775p7b68eb4d3ce0470a@mail.gmail.com> In-Reply-To: <3bbf2fe11001190927m10f73775p7b68eb4d3ce0470a@mail.gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201001191340.31700.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 19 Jan 2010 14:16:42 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx 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: Tue, 19 Jan 2010 19:16:43 -0000 On Tuesday 19 January 2010 12:27:43 pm Attilio Rao wrote: > 2010/1/19 John Baldwin : > > On Saturday 16 January 2010 7:09:38 am Attilio Rao wrote: > >> 2010/1/16 Bruce Evans : > >> > On Fri, 15 Jan 2010, Attilio Rao wrote: > >> > > >> >> 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/statclock_aliasing4.diff > >> > > >> > It seems to have the same fundamental bugs as the previous version. > >> > The atrtc interrupt is too slow to use for anything, so it should never > >> > be used if there is something better like the lapic timer available > >> > (even the i8254 is better), and using it here doesn't even fix the > >> > problem (malicious applications can very easily hide from statclock > >> > by default since the default hz is much larger than the default stathz, > >> > and malicious applications can not so easily hide from statclock > >> > irrespective > >> > of the misconfiguration of hz, since statclock is not random). See my > >> > previous reply and ftp://ftp.ee.lbl.gov/papers/statclk-usenix93.ps.Z for > >> > more details. > >> > >> Well, the primary things I wanted to fix is not the hiding of > >> malicious programs but the clock aliasing created when handling all > >> the clocks by the same source. > >> About the slowness -- I'm fine with whatever additional source to > >> LAPIC we would eventually use thus would you feel better if i8254 is > >> used replacing atrtc? > >> Also note that atrtc is the default if LAPIC cannot be used. I don't > >> understand why another source, even simpler (eg. i8254) would have > >> been used in that specific case by the 'old' code. > >> > >> What I mean, then is: I see your points, I'm not arguing that at all, > >> but the old code has other problems that gets fixed with this patch > >> (having different sources make the whole system more flexible) while > >> the new things it does introduce are secondarilly (but still: I'm fine > >> with whatever second source is picked up for statclock, profclock) if > >> you really see a concern wrt atrtc slowness. > > > > You can't use the i8254 reliable with APIC enabled. Some motherboards don't > > actually hook up IRQ 0 to pin 2. We used to support this by enabling IRQ 0 in > > the atpic and enabling the ExtINT pin to use both sets of PICs in tandem. > > However, this was very gross and had its own set of issues, so we removed the > > support for "mixed mode" a while ago. Also, the ACPI specification > > specifically forbids an OS from using "mixed mode". > > > > My feeling, btw, is that the real solution is to not use a sampling clock for > > per-process stats, but to just use the cycle counter and keep separate user, > > system, and interrupt cycle counts (like the rux_runtime we have now). This > > makes calcru() trivial and eliminates many of the weird "going backwards", > > etc. problems. The only issue with this approach is that not all platforms > > have a cheap cycle counter (many embedded platforms lack one I think), so you > > would almost need to support both modes of operation and maybe have an #define > > in to choose between the two modes. > > Generally that would be a good idea, but the problem is not only for > the architectures not supporting it, but also for architectures that > do (eg. TSC de-synchronization in some SMP environment). No, that doesn't matter. You are merely accumulating TSC deltas just as we do now for rux_runtime. For that purpose the TSC drift never matters as you are always taking deltas relative to a single CPU. -- John Baldwin