From: Andrew Morton <akpm@zip.com.au>
To: vda@port.imtp.ilyichevsk.odessa.ua
Cc: Rik van Riel <riel@conectiva.com.br>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [RFC][PATCH] iowait statistics
Date: Thu, 16 May 2002 00:41:36 -0700 [thread overview]
Message-ID: <3CE362B0.CA79EB33@zip.com.au> (raw)
In-Reply-To: <Pine.LNX.4.44L.0205132214480.32261-100000@imladris.surriel.com> <3CE073FA.57DAC578@zip.com.au> <200205151200.g4FC0MY13196@Port.imtp.ilyichevsk.odessa.ua>
Denis Vlasenko wrote:
>
> On 14 May 2002 00:18, Andrew Morton wrote:
> > Rik van Riel wrote:
> > > 4) on SMP systems the iowait time can be overestimated, no big
> > > deal IMHO but cheap suggestions for improvement are welcome
> >
> > I suspect that a number of these statistical accounting mechanisms
> > are going to break. The new irq-affinity code works awfully well.
> >
> > The kernel profiler in 2.5 doesn't work very well at present.
> > When investigating this, I ran a busy-wait process. It attached
> > itself to CPU #3 and that CPU received precisely zero interrupts
> > across a five minute period. So the profiler cunningly avoids profiling
> > busy CPUs, which is rather counter-productive. Fortunate that oprofile
> > uses NMI.
>
> What, even local APIC interrupts did not happen on CPU#3
> in these five mins?
CPU1 is busy:
quad:/home/akpm> cat /proc/interrupts ; sleep 10 ; cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3
0: 36059 33847 38948 33846 IO-APIC-edge timer
1: 1 1 1 4 IO-APIC-edge keyboard
2: 0 0 0 0 XT-PIC cascade
4: 1 1 1 0 IO-APIC-edge GDB-stub
8: 0 0 0 1 IO-APIC-edge rtc
12: 0 1 0 0 IO-APIC-edge PS/2 Mouse
14: 1 2 0 3 IO-APIC-edge ide0
15: 7558 7557 7633 8025 IO-APIC-edge ide1
19: 17088 17707 17210 18610 IO-APIC-level ide2, ide3, ide4, ide5
35: 38 71 56 174 IO-APIC-level aic7xxx
38: 955 1798 584 517 IO-APIC-level eth0
58: 25368 19911 27931 20695 IO-APIC-level aic7xxx
NMI: 164030 164030 164030 164030
LOC: 142543 142543 142542 142542
ERR: 0
MIS: 0
CPU0 CPU1 CPU2 CPU3
0: 36388 33847 39289 34178 IO-APIC-edge timer
1: 1 1 1 4 IO-APIC-edge keyboard
2: 0 0 0 0 XT-PIC cascade
4: 1 1 1 0 IO-APIC-edge GDB-stub
8: 0 0 0 1 IO-APIC-edge rtc
12: 0 1 0 0 IO-APIC-edge PS/2 Mouse
14: 1 2 0 3 IO-APIC-edge ide0
15: 7565 7557 7633 8026 IO-APIC-edge ide1
19: 17088 17707 17210 18610 IO-APIC-level ide2, ide3, ide4, ide5
35: 38 71 56 174 IO-APIC-level aic7xxx
38: 969 1798 590 525 IO-APIC-level eth0
58: 25368 19911 27931 20695 IO-APIC-level aic7xxx
NMI: 165032 165032 165032 165032
LOC: 143545 143545 143544 143544
ERR: 0
MIS: 0
-
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@zip.com.au>
To: vda@port.imtp.ilyichevsk.odessa.ua
Cc: Rik van Riel <riel@conectiva.com.br>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [RFC][PATCH] iowait statistics
Date: Thu, 16 May 2002 00:41:36 -0700 [thread overview]
Message-ID: <3CE362B0.CA79EB33@zip.com.au> (raw)
In-Reply-To: 200205151200.g4FC0MY13196@Port.imtp.ilyichevsk.odessa.ua
Denis Vlasenko wrote:
>
> On 14 May 2002 00:18, Andrew Morton wrote:
> > Rik van Riel wrote:
> > > 4) on SMP systems the iowait time can be overestimated, no big
> > > deal IMHO but cheap suggestions for improvement are welcome
> >
> > I suspect that a number of these statistical accounting mechanisms
> > are going to break. The new irq-affinity code works awfully well.
> >
> > The kernel profiler in 2.5 doesn't work very well at present.
> > When investigating this, I ran a busy-wait process. It attached
> > itself to CPU #3 and that CPU received precisely zero interrupts
> > across a five minute period. So the profiler cunningly avoids profiling
> > busy CPUs, which is rather counter-productive. Fortunate that oprofile
> > uses NMI.
>
> What, even local APIC interrupts did not happen on CPU#3
> in these five mins?
CPU1 is busy:
quad:/home/akpm> cat /proc/interrupts ; sleep 10 ; cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3
0: 36059 33847 38948 33846 IO-APIC-edge timer
1: 1 1 1 4 IO-APIC-edge keyboard
2: 0 0 0 0 XT-PIC cascade
4: 1 1 1 0 IO-APIC-edge GDB-stub
8: 0 0 0 1 IO-APIC-edge rtc
12: 0 1 0 0 IO-APIC-edge PS/2 Mouse
14: 1 2 0 3 IO-APIC-edge ide0
15: 7558 7557 7633 8025 IO-APIC-edge ide1
19: 17088 17707 17210 18610 IO-APIC-level ide2, ide3, ide4, ide5
35: 38 71 56 174 IO-APIC-level aic7xxx
38: 955 1798 584 517 IO-APIC-level eth0
58: 25368 19911 27931 20695 IO-APIC-level aic7xxx
NMI: 164030 164030 164030 164030
LOC: 142543 142543 142542 142542
ERR: 0
MIS: 0
CPU0 CPU1 CPU2 CPU3
0: 36388 33847 39289 34178 IO-APIC-edge timer
1: 1 1 1 4 IO-APIC-edge keyboard
2: 0 0 0 0 XT-PIC cascade
4: 1 1 1 0 IO-APIC-edge GDB-stub
8: 0 0 0 1 IO-APIC-edge rtc
12: 0 1 0 0 IO-APIC-edge PS/2 Mouse
14: 1 2 0 3 IO-APIC-edge ide0
15: 7565 7557 7633 8026 IO-APIC-edge ide1
19: 17088 17707 17210 18610 IO-APIC-level ide2, ide3, ide4, ide5
35: 38 71 56 174 IO-APIC-level aic7xxx
38: 969 1798 590 525 IO-APIC-level eth0
58: 25368 19911 27931 20695 IO-APIC-level aic7xxx
NMI: 165032 165032 165032 165032
LOC: 143545 143545 143544 143544
ERR: 0
MIS: 0
-
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
next prev parent reply other threads:[~2002-05-16 7:37 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-05-14 1:19 [RFC][PATCH] iowait statistics Rik van Riel
2002-05-14 1:19 ` Rik van Riel
2002-05-14 2:18 ` Andrew Morton
2002-05-14 2:18 ` Andrew Morton
2002-05-14 12:30 ` Rik van Riel
2002-05-14 12:30 ` Rik van Riel
2002-05-15 17:02 ` Denis Vlasenko
2002-05-15 17:02 ` Denis Vlasenko
2002-05-16 7:41 ` Andrew Morton [this message]
2002-05-16 7:41 ` Andrew Morton
2002-05-16 14:04 ` Denis Vlasenko
2002-05-14 15:39 ` William Lee Irwin III
2002-05-14 15:39 ` William Lee Irwin III
2002-05-14 16:36 ` Rik van Riel
2002-05-14 16:36 ` Rik van Riel
2002-05-14 16:54 ` William Lee Irwin III
2002-05-14 16:54 ` William Lee Irwin III
2002-05-15 17:17 ` Denis Vlasenko
2002-05-15 17:17 ` Denis Vlasenko
2002-05-15 14:03 ` Rik van Riel
2002-05-15 14:03 ` Rik van Riel
2002-05-15 20:17 ` Denis Vlasenko
2002-05-15 20:17 ` Denis Vlasenko
2002-05-15 16:13 ` Rik van Riel
2002-05-15 16:13 ` Rik van Riel
2002-05-15 16:21 ` William Lee Irwin III
2002-05-15 16:21 ` William Lee Irwin III
2002-05-15 17:00 ` William Lee Irwin III
2002-05-15 17:00 ` William Lee Irwin III
2002-05-15 18:16 ` Bill Davidsen
2002-05-15 18:16 ` Bill Davidsen
2002-05-15 18:30 ` William Lee Irwin III
2002-05-15 18:30 ` William Lee Irwin III
2002-05-15 18:33 ` Rik van Riel
2002-05-15 18:33 ` Rik van Riel
2002-05-15 18:46 ` William Lee Irwin III
2002-05-15 18:46 ` William Lee Irwin III
2002-05-15 19:00 ` Rik van Riel
2002-05-15 19:00 ` Rik van Riel
2002-05-16 11:42 ` Denis Vlasenko
2002-05-16 11:42 ` Denis Vlasenko
2002-05-16 9:49 ` Leigh Brown
2002-05-16 14:51 ` Rik van Riel
2002-05-16 16:44 ` Leigh Brown
2002-05-17 8:02 ` Jens Axboe
2002-05-16 11:14 ` Denis Vlasenko
2002-05-16 11:14 ` Denis Vlasenko
2002-05-15 15:15 ` Bill Davidsen
2002-05-15 15:15 ` Bill Davidsen
2002-05-16 10:58 ` Denis Vlasenko
2002-05-16 10:58 ` Denis Vlasenko
2002-05-14 18:19 ` Martin J. Bligh
2002-05-14 18:19 ` Martin J. Bligh
2002-05-15 1:31 ` Bill Davidsen
2002-05-15 1:41 ` William Lee Irwin III
2002-05-15 1:41 ` William Lee Irwin III
2002-05-15 14:39 ` Bill Davidsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3CE362B0.CA79EB33@zip.com.au \
--to=akpm@zip.com.au \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=riel@conectiva.com.br \
--cc=vda@port.imtp.ilyichevsk.odessa.ua \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.