[PATCH] Statclock aliasing by LAPIC

[John Baldwin]

On Tuesday 19 January 2010 1:53:32 pm Bruce Evans wrote:
> On Tue, 19 Jan 2010, John Baldwin wrote:
> >> 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".
> 
> I thought that recent changes reenabled some of this.  And what's to stop
> some motherboards breaking the RTC too?

No, mixed mode is still very much disabled.  The RTC is different because I
believe Windows still uses it (or at least some older versions have used it
with the APIC in the past) so that it actually gets tested for WHQL testing
as opposed to IRQ 0 which does not get tested.

I think on some recentish Nvidia chipsets the ISA timer was actually hooked
directly to pin 0 on the first I/O APIC.  There was no ExtInt pin, and pin 2
was just dead.  We had a separate quirk to deal with that that I think is
still present (though now effectively unused).

> > 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).
> 
> The total runtime info is already available (in rux_runtime).  It is
> the main thing that we use to see that scheduling is broken :-) -- we
> see that the runtime is too large or small relative to %CPU.  I think
> using this and never using ticks for scheduling would work OK.  Schedulers
> shouldn't care about the difference between user and sys time.  Something
> like this is also needed for tickless kernels.

I mostly care about splitting up the timers to attempt to remove the need
for statclock() by making more stats event-driven rather than sampled (to
help with a tickless kernel).  I also would like to simplify calcru() and
remove the weird hacks to satisfy monoticity (sp?).

-- 
John Baldwin