Date: Sun, 17 Feb 2008 22:18:57 +0530 From: Girish Venkatachalam <girishvenkatachalam@gmail.com> To: freebsd-hackers@freebsd.org Subject: Re: cpu stats and another interrupt question Message-ID: <20080217164857.GA15657@saraswathy.madambakam.org> In-Reply-To: <47B8055C.4060305@icyb.net.ua> References: <47B4A514.1020103@icyb.net.ua> <47B8055C.4060305@icyb.net.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080217164857.GA15657>