Skip site navigation (1)Skip section navigation (2)
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>