From owner-freebsd-arch@FreeBSD.ORG Tue Jan 19 17:27:45 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 500E11065693; Tue, 19 Jan 2010 17:27:45 +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 8654C8FC1D; Tue, 19 Jan 2010 17:27:44 +0000 (UTC) Received: by fxm10 with SMTP id 10so958782fxm.14 for ; Tue, 19 Jan 2010 09:27:43 -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=clgQD7jQ0GgLrxN/KsTJ9eFVWWzurM7Md4HCKzTEn2k=; b=VNUmy91672iLKKVnXqPz4aY5N5ASRTVyBs5SHjTYbpEOB3F78aVxI+hUgq1QDoNJL6 ulVvHK3ZFZbvSETCg8HUa7PGo0xkNd1b2tPSOlRCylsysE9WSZY2LFZQqRXcoWvSCGQb fw061JocorWqvIiWcVmmxyxRaabCozkFMgLjM= 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=waMiI3Bq5oCygHZywHpQdAoHLJwUOLk9mr7NTw6042CdB44EH2LfVnp5uJtIQGghAH 1/SHCdF+z9qsy92Q4WDMHz3IyAqtT+wz3+tqVV0qlncOePKqL9NBdYaOGT1bh3+jO1Ua IOcKQXjotEkRgOnzXMwuHSIC+0rhEoIYjw+jU= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.223.76.69 with SMTP id b5mr9603579fak.20.1263922063338; Tue, 19 Jan 2010 09:27:43 -0800 (PST) In-Reply-To: <201001191144.23299.jhb@freebsd.org> References: <3bbf2fe10911271542h2b179874qa0d9a4a7224dcb2f@mail.gmail.com> <20100116205752.J64514@delplex.bde.org> <3bbf2fe11001160409w1dfdbb9j36458c52d596c92a@mail.gmail.com> <201001191144.23299.jhb@freebsd.org> Date: Tue, 19 Jan 2010 18:27:43 +0100 X-Google-Sender-Auth: b8b5d589fbfd4069 Message-ID: <3bbf2fe11001190927m10f73775p7b68eb4d3ce0470a@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: Tue, 19 Jan 2010 17:27:45 -0000 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/stat= clock_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 neve= r >> > 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). =C2=A0S= ee my >> > previous reply and ftp://ftp.ee.lbl.gov/papers/statclk-usenix93.ps.Z f= or >> > 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. =C2=A0Some motherboar= ds don't > actually hook up IRQ 0 to pin 2. =C2=A0We used to support this by enablin= g 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. =C2=A0Also, 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 us= er, > system, and interrupt cycle counts (like the rux_runtime we have now). = =C2=A0This > makes calcru() trivial and eliminates many of the weird "going backwards"= , > etc. problems. =C2=A0The only issue with this approach is that not all pl= atforms > 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 #d= efine > 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). Attilio > Even in that mode you still need a sampling clock I think for cp_time[] a= nd > cp_times[], but individual threads can no longer "hide" as we would be ke= eping > precise timing stats. Yes, cp_times do require a sampling clock, I guess. Attilio --=20 Peace can only be achieved by understanding - A. Einstein