Date: Tue, 19 Jan 2010 18:41:23 +0100 From: Attilio Rao <attilio@freebsd.org> To: Scott Long <scottl@samsco.org> Cc: FreeBSD Arch <arch@freebsd.org>, Ed Maste <emaste@freebsd.org> Subject: Re: [PATCH] Statclock aliasing by LAPIC Message-ID: <3bbf2fe11001190941s37f62c48tb91be0061b658b2c@mail.gmail.com> In-Reply-To: <274B568B-81D9-4554-8C3A-888FF0CD7B08@samsco.org> References: <3bbf2fe10911271542h2b179874qa0d9a4a7224dcb2f@mail.gmail.com> <20100116205752.J64514@delplex.bde.org> <3bbf2fe11001160409w1dfdbb9j36458c52d596c92a@mail.gmail.com> <201001191144.23299.jhb@freebsd.org> <3bbf2fe11001190927m10f73775p7b68eb4d3ce0470a@mail.gmail.com> <274B568B-81D9-4554-8C3A-888FF0CD7B08@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
2010/1/19 Scott Long <scottl@samsco.org>: > On Jan 19, 2010, at 10:27 AM, Attilio Rao wrote: >> >> 2010/1/19 John Baldwin <jhb@freebsd.org>: >>> >>> On Saturday 16 January 2010 7:09:38 am Attilio Rao wrote: >>>> >>>> 2010/1/16 Bruce Evans <brde@optusnet.com.au>: >>>>> >>>>> 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/st= atclock_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 nev= er >>>>> 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 stath= z, >>>>> and malicious applications can not so easily hide from statclock >>>>> irrespective >>>>> of the misconfiguration of hz, since statclock is not random). =C2=A0= See my >>>>> previous reply and >>>>> ftp://ftp.ee.lbl.gov/papers/statclk-usenix93.ps.Z=C2=A0for >>>>> 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 motherbo= ards >>> don't >>> actually hook up IRQ 0 to pin 2. =C2=A0We used to support this by enabl= ing IRQ >>> 0 in >>> the atpic and enabling the ExtINT pin to use both sets of PICs in tande= m. >>> However, this was very gross and had its own set of issues, so we remov= ed >>> the >>> support for "mixed mode" a while ago. =C2=A0Also, the ACPI specificatio= n >>> specifically forbids an OS from using "mixed mode". >>> >>> My feeling, btw, is that the real solution is to not use a sampling clo= ck >>> 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). >>> =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 >>> 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 <machine/param.h> 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). >> > > For process stats, TSC desync isn't a big problem. =C2=A0As a process mig= rates > from one CPU to the other, its stats from the old cpu will be recorded, t= hen > stats will be started on the new cpu. =C2=A0The only problem here is with > normalizing the different TSC's to a common reference. =C2=A0Maybe that c= an be > done when computing cp_times? =C2=A0This is definitely a case where 'perf= ect' is > the enemy of 'a hell of a lot better than we have now'. I wouldn't like to be mistaken, but IIRC in some benchmarks kris@ did in the past years we were seeing TSC timers litterally going backwards after the de-synchronization (even on absolute measurement). Attilio --=20 Peace can only be achieved by understanding - A. Einstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3bbf2fe11001190941s37f62c48tb91be0061b658b2c>