Date: Wed, 2 Jul 2003 11:40:02 -0400 From: Jake Burkholder <jake@k6.locore.ca> To: Marcel Moolenaar <marcel@xcllnt.net>, sparc64@freebsd.org Subject: Re: OFW_NEWPCI dmesg diffs Message-ID: <20030702154002.GA40152@k6.locore.ca> In-Reply-To: <20030702040928.GC58048@funkthat.com> References: <20030702040139.GA11199@dhcp01.pn.xcllnt.net> <20030702040928.GC58048@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Apparently, On Tue, Jul 01, 2003 at 09:09:28PM -0700, John-Mark Gurney said words to the effect of; > Marcel Moolenaar wrote this message on Tue, Jul 01, 2003 at 21:01 -0700: > > BTW: vmstat -i doesn't work: > > > > sparc% vmstat -i > > interrupt total rate > > Total 0 0 > > sparc% > > I have patches to fix this. > > But, I the problem is that both soft interrupts and vector interrupts > are useful to know. All vector interrupts are dispatched via soft > interrupts, so if we count both, the interrupt count is double. We > need soft interrupts if we want to see the clock ticking. > > bash-2.05b$ vmstat -i > interrupt total rate > stray 1 0 > pil 1 0 > ithrd pil2 69163 16 > gem0 vec2012 27748 6 > gem1 vec1990 70 0 > atapci0 vec1996 41345 9 > tick pil14 421278 99 > Total 559606 132 > > notice that ithrd is equal to gem0 + gem1 + atapci0. pil is the > priority interrupt level (aka soft interrupts). > > Comments? Do we count both? or not include soft interrupts? or not > include the ithrd pil? I think counting both is fine for now. Eventually what I intend to do is change tick handling so that it looks more like a vectored interrupt. The pil14 handler would queue and reprioritize the tick interrupts so that tick can be re-armed independent of the handler actually running. The soft interrupt that drives hardclock would have a vector number (outside of the normal 11 bits for hardware interrupts), and be counted uniformly. Jake
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030702154002.GA40152>