cpu stats and another interrupt question

[Girish Venkatachalam]

On 11:58:52 Feb 17, Andriy Gapon wrote:
> 
> Come on, guys, simple yes or no would be enough for me :-)
> 

Okay. I am going to give my free advice. 

You obviously know what that means. Please take it with a pinch of salt.

> on 14/02/2008 22:31 Andriy Gapon said the following:
> > 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 ?

I have no clue about older PCs. I am quite young myself. :)

However my "guess" would be that RTC is unrelated to what you are
talking. Interrupts and CPU time ticks have nothing to do with the RTC
chip.

Please correct me if I am wrong.

CPU ticks are generated by a separate crystal inside the uC itself. And
these software interrupts have to be serviced or else you will lose
time. This can sometimes happen but in extreme cases this could affect
processes in an adverse manner of course.

Years ago I was in a similar situation when working on Novell Netware.

That said I have no clue about older PCs. So I could be entirely wrong
here...

> > 
> > 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.

If you are talking about the 8259C PIC then where are two
8259s coming from?

I  was under the impression that one PIC is sufficient for a typical
daisy chained interrupt handling mechanism.

Yet another wild guess.

Now it is time to sleep. 

Good nite. 

-Girish