9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* [9fans] Interrupt saturation
@ 2010-02-28  9:55 lucio
  2010-02-28 14:50 ` erik quanstrom
  2010-03-01  3:13 ` ron minnich
  0 siblings, 2 replies; 8+ messages in thread
From: lucio @ 2010-02-28  9:55 UTC (permalink / raw)
  To: 9fans

The workstation I'm using presently seems to trigger as many
interrupts as stats(1) can display, while the syscall graph is also
extremely busy.

I presume this is anomalous.  Killing the single instance of
timesync(1) does not seem to make any difference at all.

Any suggestions to where I should look?  I'm not running anything that
would make me suspicious, but I'm going to restart the system just to
check.

++L




^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [9fans] Interrupt saturation
  2010-02-28  9:55 [9fans] Interrupt saturation lucio
@ 2010-02-28 14:50 ` erik quanstrom
  2010-03-01  3:13 ` ron minnich
  1 sibling, 0 replies; 8+ messages in thread
From: erik quanstrom @ 2010-02-28 14:50 UTC (permalink / raw)
  To: lucio, 9fans

On Sun Feb 28 04:57:09 EST 2010, lucio@proxima.alt.za wrote:
> The workstation I'm using presently seems to trigger as many
> interrupts as stats(1) can display, while the syscall graph is also
> extremely busy.
>
> I presume this is anomalous.  Killing the single instance of
> timesync(1) does not seem to make any difference at all.
>
> Any suggestions to where I should look?  I'm not running anything that
> would make me suspicious, but I'm going to restart the system just to
> check.

the exact number would be interesting.  i've added a field
to '#P/irqalloc' on my kernels that is the count of interrupts
per vector:

; cat '#P/irqalloc'
          3           0                    0 debugpt
          7           0                    0 mathemu
          8           0                    0 doublefault
          9           0                    0 mathover
         14           0                    0 fault386
         15           0                    0 unexpected
         16           0                    0 matherror
         50          18          18822033321 clock
         51          19                    0 lapicerror
         63          31                    0 lapicspurious
         65           1                    2 kbd
         73           9            772061679 ether0
         81          10              8689592 ether1
         89          11             11583013 ether2
         97           4                 5092 COM1
        105          14                    5 sdC (ata)

perhaps this would be useful.  you can pick it out
of ftp://ftp.quanstro.net/other/kernel.mkfs.bz2
in pc/trap.c.

- erik



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [9fans] Interrupt saturation
  2010-02-28  9:55 [9fans] Interrupt saturation lucio
  2010-02-28 14:50 ` erik quanstrom
@ 2010-03-01  3:13 ` ron minnich
  2010-03-01 17:39   ` lucio
  1 sibling, 1 reply; 8+ messages in thread
From: ron minnich @ 2010-03-01  3:13 UTC (permalink / raw)
  To: lucio, Fans of the OS Plan 9 from Bell Labs

On Sun, Feb 28, 2010 at 1:55 AM,  <lucio@proxima.alt.za> wrote:
> The workstation I'm using presently seems to trigger as many
> interrupts as stats(1) can display, while the syscall graph is also
> extremely busy.

workstation only? I.e. it is not running venti?

ron



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [9fans] Interrupt saturation
  2010-03-01  3:13 ` ron minnich
@ 2010-03-01 17:39   ` lucio
  2010-03-01 18:00     ` erik quanstrom
  0 siblings, 1 reply; 8+ messages in thread
From: lucio @ 2010-03-01 17:39 UTC (permalink / raw)
  To: 9fans

> workstation only? I.e. it is not running venti?

Thanks for the chance to follow up.  I implemented quanstro's
enhancement to /proc, and this is what I get right now, some
twenty-four hours after starting up:

          3           0                    0 debugpt
          7           0                    0 mathemu
          8           0                    0 doublefault
          9           0                    0 mathover
         14           0                    0 fault386
         15           0                    0 unexpected
         16           0                    0 matherror
         50          18             76160483 clock
         51          19                    0 lapicerror
         63          31                    0 lapicspurious
         65           1                15761 kbd
         73          11              9799735 ether0
         81           6                    0 floppy
         89           3               124777 ac97audio
         97           5                    0 usbuhci
        105           9                    0 usbuhci
        113          11                    0 usbuhci
        121          10                    0 usbehci
        129          15                   82 sdD (ata)
        137           7                    0 lpt
        145          12               213171 kbdaux

The stuff Erik displayed looked a lot worse, so maybe it's just that
I'm not used to having stats(1) display a solid block for the
Interrupts.  Still, I wish cpu cycles could be better utilised.

And, tes, it's effectively a diskless terminal.

++L




^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [9fans] Interrupt saturation
  2010-03-01 17:39   ` lucio
@ 2010-03-01 18:00     ` erik quanstrom
  2010-03-01 19:12       ` lucio
  0 siblings, 1 reply; 8+ messages in thread
From: erik quanstrom @ 2010-03-01 18:00 UTC (permalink / raw)
  To: lucio, 9fans

On Mon Mar  1 12:53:59 EST 2010, lucio@proxima.alt.za wrote:
> > workstation only? I.e. it is not running venti?
>
> Thanks for the chance to follow up.  I implemented quanstro's
> enhancement to /proc, and this is what I get right now, some
> twenty-four hours after starting up:
>
>          50          18             76160483 clock
>          65           1                15761 kbd
>          73          11              9799735 ether0
>          89           3               124777 ac97audio
>         145          12               213171 kbdaux
>
> The stuff Erik displayed looked a lot worse, so maybe it's just that
> I'm not used to having stats(1) display a solid block for the
> Interrupts.  Still, I wish cpu cycles could be better utilised.
>
> And, tes, it's effectively a diskless terminal.

my machine has been up for 90+ days.

looks like you just have HZ set to 1000.
 stats isn't counting on that.

also, 113 ethernet interrupts/sec is a pretty
good clip.

- erik



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [9fans] Interrupt saturation
  2010-03-01 18:00     ` erik quanstrom
@ 2010-03-01 19:12       ` lucio
  2010-03-01 22:50         ` erik quanstrom
  0 siblings, 1 reply; 8+ messages in thread
From: lucio @ 2010-03-01 19:12 UTC (permalink / raw)
  To: 9fans

> my machine has been up for 90+ days.
>
That sure makes a difference :-)

> looks like you just have HZ set to 1000.
>  stats isn't counting on that.
>
How does one change that?

> also, 113 ethernet interrupts/sec is a pretty
> good clip.

Yes, that's also a bit steep.  Intel chip, maybe I should install the
3Com card I had on the old hardware.  I changed from a 900MHz board to
a newer, 2.6GHz device with some (additional) peripherals built in.
Didn't expect a weird stats display.

++L




^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [9fans] Interrupt saturation
  2010-03-01 19:12       ` lucio
@ 2010-03-01 22:50         ` erik quanstrom
  2010-03-02  4:01           ` lucio
  0 siblings, 1 reply; 8+ messages in thread
From: erik quanstrom @ 2010-03-01 22:50 UTC (permalink / raw)
  To: lucio, 9fans

> > looks like you just have HZ set to 1000.
> >  stats isn't counting on that.
> >
> How does one change that?

i wouldn't suspect that one would want to.
the higher clock rate allows more precise
scheduling.  the extra overhead should be
unnoticable on a 2.6ghz processor, except via
stats.

> > also, 113 ethernet interrupts/sec is a pretty
> > good clip.
>
> Yes, that's also a bit steep.  Intel chip, maybe I should install the
> 3Com card I had on the old hardware.  I changed from a 900MHz board to
> a newer, 2.6GHz device with some (additional) peripherals built in.
> Didn't expect a weird stats display.

i would imagine that you're getting this kind of
interrupt load from the nic because you're getting
a lot of packets.

do you suspect the interrupt load is a problem, or
are you just bothered by stats?

- erik



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [9fans] Interrupt saturation
  2010-03-01 22:50         ` erik quanstrom
@ 2010-03-02  4:01           ` lucio
  0 siblings, 0 replies; 8+ messages in thread
From: lucio @ 2010-03-02  4:01 UTC (permalink / raw)
  To: 9fans

> do you suspect the interrupt load is a problem, or
> are you just bothered by stats?

The latter, I replaced the workstation hardware bacause of a power
supply fan failure and the most noticeable difference was stats'
behaviour.

In passing, has anyone looked at fixing the uneven width of the last
column in a multi-host stats display?  I tried, but it seemed such a
convoluted computation I couldn't figure out how the last column's
width turned out a good few pixels wider than the others.  This is
particularly visible with many narrow columns (I have had up to eight
of them).

++L




^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2010-03-02  4:01 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-02-28  9:55 [9fans] Interrupt saturation lucio
2010-02-28 14:50 ` erik quanstrom
2010-03-01  3:13 ` ron minnich
2010-03-01 17:39   ` lucio
2010-03-01 18:00     ` erik quanstrom
2010-03-01 19:12       ` lucio
2010-03-01 22:50         ` erik quanstrom
2010-03-02  4:01           ` lucio

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).