From: "Bill Rugolsky Jr." <brugolsky@telemetry-investments.com>
To: Andi Kleen <ak@suse.de>
Cc: Jason Baron <jbaron@redhat.com>, linux-kernel@vger.kernel.org
Subject: Re: AMD64 X2 lost ticks on PM timer
Date: Wed, 1 Mar 2006 13:07:14 -0500 [thread overview]
Message-ID: <20060301180714.GD20092@ti64.telemetry-investments.com> (raw)
In-Reply-To: <200603011647.34516.ak@suse.de>
On Wed, Mar 01, 2006 at 04:47:33PM +0100, Andi Kleen wrote:
> > My guess is the sata_nv driver, as it happens during heavy local file read.
> > The machines all have 2-4 SATA WD Raptors connected to the mobo.
>
> Are you accessing all these disks in parallel with that cpio? If
> yes could you try it with only a single disk?
Yes, all of the hosts are LVM2 over MD RAID1. The PostgreSQL
LV has striping over the two MD RAID1 PVs.
> My box only has a single SATA disk. Maybe there is some
> corner case in that SATA driver that leaks interrupt state
> and it's only turned on later by idle or softirq then.
Good call! Stressing one disk results in no lost ticks.
I stuck a spare disk in one of the workstations that has its system
partitions on Ext3/LVM2/MD-RAID1, and then copied the 9GB /usr to
a raw Ext3 partition on the new disk:
find usr | cpio -pdum /opt
That resulted in:
Mar 1 11:39:27 ti94 kernel: time.c: Lost 1 timer tick(s)! rip __do_softirq+0x55/0xd4)
Mar 1 11:39:41 ti94 kernel: time.c: Lost 1 timer tick(s)! rip __do_softirq+0x55/0xd4)
Mar 1 11:40:37 ti94 kernel: time.c: Lost 3 timer tick(s)! rip __do_softirq+0x55/0xd4)
Mar 1 11:40:40 ti94 kernel: time.c: Lost 6 timer tick(s)! rip __do_softirq+0x55/0xd4)
Mar 1 11:40:41 ti94 kernel: time.c: Lost 1 timer tick(s)! rip __do_softirq+0x55/0xd4)
Mar 1 11:40:42 ti94 kernel: time.c: Lost 1 timer tick(s)! rip __do_softirq+0x55/0xd4)
Mar 1 11:40:50 ti94 kernel: time.c: Lost 1 timer tick(s)! rip __do_softirq+0x55/0xd4)
Mar 1 11:40:54 ti94 kernel: time.c: Lost 1 timer tick(s)! rip __do_softirq+0x55/0xd4)
Mar 1 11:40:57 ti94 kernel: time.c: Lost 1 timer tick(s)! rip __do_softirq+0x55/0xd4)
Mar 1 11:41:01 ti94 kernel: time.c: Lost 2 timer tick(s)! rip __do_softirq+0x55/0xd4)
Mar 1 11:41:06 ti94 kernel: time.c: Lost 1 timer tick(s)! rip __do_softirq+0x55/0xd4)
Mar 1 11:41:12 ti94 kernel: time.c: Lost 1 timer tick(s)! rip __do_softirq+0x55/0xd4)
Mar 1 11:41:17 ti94 kernel: time.c: Lost 2 timer tick(s)! rip __do_softirq+0x55/0xd4)
Mar 1 11:41:21 ti94 kernel: time.c: Lost 3 timer tick(s)! rip __do_softirq+0x55/0xd4)
Mar 1 11:41:27 ti94 kernel: time.c: Lost 4 timer tick(s)! rip __do_softirq+0x55/0xd4)
Mar 1 11:41:27 ti94 kernel: time.c: Lost 1 timer tick(s)! rip __do_softirq+0x55/0xd4)
Mar 1 11:41:29 ti94 kernel: time.c: Lost 3 timer tick(s)! rip _spin_unlock_irqrestore+0xb/0xd)
Mar 1 11:41:42 ti94 kernel: time.c: Lost 1 timer tick(s)! rip __do_softirq+0x55/0xd4)
Mar 1 11:41:43 ti94 kernel: time.c: Lost 2 timer tick(s)! rip __do_softirq+0x55/0xd4)
Mar 1 11:41:43 ti94 kernel: time.c: Lost 1 timer tick(s)! rip __do_softirq+0x55/0xd4)
Mar 1 11:41:46 ti94 kernel: time.c: Lost 2 timer tick(s)! rip __do_softirq+0x55/0xd4)
Mar 1 11:41:55 ti94 kernel: time.c: Lost 1 timer tick(s)! rip __do_softirq+0x55/0xd4)
Mar 1 11:41:55 ti94 kernel: time.c: Lost 2 timer tick(s)! rip default_idle+0x37/0x7a)
Mar 1 11:41:57 ti94 kernel: time.c: Lost 1 timer tick(s)! rip default_idle+0x37/0x7a)
Mar 1 11:41:57 ti94 kernel: time.c: Lost 1 timer tick(s)! rip default_idle+0x37/0x7a)
Mar 1 11:42:00 ti94 kernel: time.c: Lost 2 timer tick(s)! rip default_idle+0x37/0x7a)
Mar 1 11:42:00 ti94 kernel: time.c: Lost 1 timer tick(s)! rip default_idle+0x37/0x7a)
Mar 1 11:42:00 ti94 kernel: time.c: Lost 2 timer tick(s)! rip default_idle+0x37/0x7a)
...
After a umount/mount on /opt, I did
find /opt | cpio -o > /dev/null
and got no lost ticks in the log. My "nice --10 ./trtc" gave me:
rugolsky@ti94: tail +10 one-disk | grep -v '=125'
1141232738:578610: rtc 448 int 124 0 (=124)
1141232807:67036: rtc 464 int 0 124 (=124)
1141232875:557669: rtc 448 int 0 124 (=124)
I converted the raw EXT3 partition to a degraded MD RAID1, and again
got no lost ticks. Then I created a PV/VG/LV/Ext3 on top of the degraded MD RAID1,
populated it, and re-read it; once again, there were no lost ticks on the
single-disk read.
Time to instrument sata_nv, I suppose. Many thanks for helping to narrow this
down.
-Bill
next prev parent reply other threads:[~2006-03-01 18:07 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-27 21:22 bubshait
2006-02-27 22:21 ` Bill Rugolsky Jr.
2006-02-27 22:47 ` Jason Baron
2006-02-28 7:41 ` Abdulla Bubshait
2006-02-28 22:00 ` Bill Rugolsky Jr.
2006-02-28 23:53 ` Andi Kleen
2006-03-01 14:46 ` Bill Rugolsky Jr.
2006-03-01 14:56 ` Andi Kleen
2006-03-01 15:43 ` Bill Rugolsky Jr.
2006-03-01 15:47 ` Andi Kleen
2006-03-01 18:07 ` Bill Rugolsky Jr. [this message]
2006-03-01 18:29 ` Andi Kleen
2006-03-01 19:16 ` Lee Revell
2006-03-03 19:18 ` Bill Rugolsky Jr.
2006-03-03 21:26 ` Lee Revell
2006-03-03 22:09 ` Jeff Garzik
2006-03-03 23:43 ` Bill Rugolsky Jr.
2006-03-03 23:46 ` Jeff Garzik
2006-03-03 23:49 ` Lee Revell
2006-03-04 0:08 ` Andi Kleen
2006-03-04 0:07 ` Andi Kleen
[not found] ` <20060315213638.GA17817@ti64.telemetry-investments.com>
2006-03-15 21:45 ` libata/sata_nv latency on NVIDIA CK804 [was Re: AMD64 X2 lost ticks on PM timer] Lee Revell
2006-03-15 21:58 ` Ingo Molnar
2006-03-15 22:00 ` Ingo Molnar
2006-03-15 22:25 ` Jeff Garzik
2006-03-16 15:13 ` Alan Cox
2006-03-16 16:57 ` Bill Rugolsky Jr.
2006-03-22 16:09 ` Andi Kleen
2006-03-22 18:39 ` Bill Rugolsky Jr.
2006-03-22 23:07 ` Bill Rugolsky Jr.
2006-03-15 22:22 ` Jeff Garzik
2006-03-15 22:24 ` Ingo Molnar
2006-03-15 22:36 ` Bill Rugolsky Jr.
2006-03-15 22:46 ` Ingo Molnar
2006-03-15 22:48 ` Jeff Garzik
2006-03-15 23:31 ` Lee Revell
2006-03-15 21:50 ` Ingo Molnar
2006-03-15 22:11 ` Ingo Molnar
2006-03-15 22:33 ` Jeff Garzik
2006-03-15 22:44 ` Ingo Molnar
2006-03-15 22:50 ` Jeff Garzik
2006-03-15 23:14 ` Bill Rugolsky Jr.
2006-03-15 23:44 ` Lee Revell
[not found] ` <20060316002133.GE17817@ti64.telemetry-investments.com>
2006-03-16 0:48 ` Long latencies with MD RAID 1 [was Re: libata/sata_nv latency on NVIDIA CK804 ] Lee Revell
2006-03-16 3:15 ` libata/sata_nv latency on NVIDIA CK804 [was Re: AMD64 X2 lost ticks on PM timer] Bill Rugolsky Jr.
2006-03-16 4:20 ` Lee Revell
2006-03-16 9:18 ` Ingo Molnar
2006-03-16 14:42 ` Gabor Gombas
2006-03-16 0:01 ` Lee Revell
2006-03-16 0:14 ` Jeff Garzik
2006-03-15 22:30 ` Jeff Garzik
2006-03-15 22:36 ` Ingo Molnar
2006-03-15 22:04 ` [patch] latency-tracing-v2.6.16.patch Ingo Molnar
2006-03-15 22:32 ` Bill Rugolsky Jr.
2006-03-16 9:18 ` Ingo Molnar
2006-03-04 12:06 ` AMD64 X2 lost ticks on PM timer Martin Schlemmer
2006-03-05 7:07 ` Alexander Samad
2006-03-02 15:47 ` Gabor Gombas
2006-02-28 21:17 ` Abdulla Bubshait
2006-03-06 17:37 [RFC] Encrypting file system Michael Halcrow
2006-03-06 21:36 ` AMD64 X2 lost ticks on PM timer Timo Schroeter
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=20060301180714.GD20092@ti64.telemetry-investments.com \
--to=brugolsky@telemetry-investments.com \
--cc=ak@suse.de \
--cc=jbaron@redhat.com \
--cc=linux-kernel@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®