cpu stats and another interrupt question


Dear hackers,
I'd like to check with you if my understanding of some code is correct.

If we speak about a typical older i386 system, with UP and "AT" PIC, I
think this is how the CPU utilization stats are collected.
RTC is configured to generate interrupts (IRQ8) 128 times per second.
Each time interrupt is generated RTC interrupt handler (I will use
simple non technical terms) takes a peek at what was interrupted and
depending on the properties of that thing (kernel thread) bills a tick
to particular category. E.g. if it sees that the "idle" thread is
interrupted then a tick is billed to "idle", if an interrupt thread is
interrupted (software or hardware) then a tick is billed to interrupt,
if a thread is running user-mode code then a tick is billed to "user" or
"nice", otherwise it's "system".
I understand that I oversimplify, but is the above correct in general ?

Another, unrelated, question.
Considering this snippet from sys/i386/isa/atpic.c, i8259_init():
#ifndef PC98
/* OCW2_L1 sets priority order to 3-7, 0-2 (com2 first). */
if (!slave)
outb(pic->at_ioaddr, OCW2_R | OCW2_SL | OCW2_L1);
#endif

Do I understand correctly the code and the comment that here we use a
feature of 8259 PIC that can be called "cyclic shift of interrupt
priorities" ?
So, we really have the following order of interrupts, from higher
priority to lower: 3-7,0,1,8-15? Considering two chained 8259s, of course.

--
Andriy Gapon
_______________________________________________
freebsd-hackers@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: [PATCH 1/6] new timeofday core subsystem for -mm (v.B3)
    ... tick compensation. ... or interrupt starvation. ... almost all of the arch generic time code. ... I have come to believe the current arch generic tick based timekeeping ...
    (Linux-Kernel)
  • Re: Fix time going backward with clock=pit [1/2]
    ... Oh, I see, you were also assuming there's a way to fix that. ... return more than a jiffy is dangerous if we can ever lose a tick (due to ... Is there really no way to detect the pending interrupt (e.g. ... It's not that important if it's not completely correct for SMP systems, ...
    (Linux-Kernel)
  • Re: OEMGetRealTime and SoftRTC flag
    ... You could be correct about the interrupt priorities, ... already running ISR. ... may have been longer than one millisecond since the last tick interrupt. ...
    (microsoft.public.windowsce.platbuilder)
  • Re: [RFC][PATCH] new timeofday core subsystem (v.A0)
    ... and this is the rate at which jiffies must tick. ... > What do you do if one clock lacks resolution, and the other clock lacks digits? ... You'll just need an interrupt before roll-over. ...
    (Linux-Kernel)
  • Re: [PATCH 1/3] dynticks - implement no idle hz for x86
    ... necessary to reprogram the interrupt is about the same as how long we ... h/w controls the timer interrupt frequency. ... want one CPU to be the "last" CPU going idle:) ... > After a cpu woke up some code need to check if a tick has passed or not. ...
    (Linux-Kernel)