All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steven Haigh <netwiz@crc.id.au>
To: Jan Beulich <JBeulich@suse.com>
Cc: xen-devel@lists.xen.org
Subject: Re: Kernel 3.7.[12] - irq 16: nobody cared
Date: Wed, 16 Jan 2013 21:13:11 +1100	[thread overview]
Message-ID: <50F67D37.3020008@crc.id.au> (raw)
In-Reply-To: <50F6897B02000078000B617D@nat28.tlf.novell.com>


[-- Attachment #1.1: Type: text/plain, Size: 5610 bytes --]

On 16/01/2013 9:05 PM, Jan Beulich wrote:
>>>> On 16.01.13 at 10:54, Steven Haigh <netwiz@crc.id.au> wrote:
>> So far, I have:
>> # uptime
>>    20:50:40 up 1 day,  1:11,  1 user,  load average: 0.36, 0.17, 0.13
>>
>> As I mentioned, I moved the sata card to the second 16x PCIe slot in the
>> mainboard - which changed the IRQ from 16 to 19. Currently I see:
>> # grep sata_mv /proc/interrupts
>>    19:   21243495  xen-pirq-ioapic-level  sata_mv
>>
>> Which is interestingly more than the onboard SATA ports:
>> # grep ahci /proc/interrupts
>>    50:    9004117  xen-pirq-msi       ahci
> Whether the former count is too high depends on the I/O amount
> going through each controller. Of course it is possible for there to
> be spikes that usually don't reach the 99,900 cutoff point, but
> once in a while do. Figuring whether that's the case would require
> adding a little bit more verbosity to
> kernel/irq/spurious.c:note_interrupt(), e.g. to warn when having
> reached half the threshold.

Interestingly, I just realised I have 3 of the 4 drives in this RAID6 on 
the sata_mv card. I did originally think I had 2 drives on the onboard 
SATA ports, and the other 2 on the sata_mv card. This would mean 3/4 of 
the IO would be going via this card - but only 1/4 on the onboard.

# lsdrv
PCI [ahci] 00:1f.2 SATA controller: Intel Corporation 6 Series/C200 
Series Chipset Family SATA AHCI Controller (rev 05)
.scsi 0:0:0:0 ATA ST380815AS {6RAB72DZ}
..sda 74.53g [8:0] Partitioned (dos)
. .sda1 200.00m [8:1] MD raid1 (1/2) (w/ sdb1) in_sync 
'localhost.localdomain:0' {9f19116a-d280-8216-cc87-af34eae68242}
. ..md0 199.99m [9:0] MD v1.0 raid1 (2) clean
. . .                 Partitioned (dos) 
{6578dbc0-9e07-4ccc-8eff-15f2a1da8df1}
. . .Mounted as /dev/md0 @ /boot
. .sda2 74.33g [8:2] MD raid1 (1/2) (w/ sdb2) in_sync 
'localhost.localdomain:1' {afb92c19-b9b1-e3ae-07af-315d738e38be}
.  .md1 74.33g [9:1] MD v1.1 raid1 (2) clean
.   .                PV LVM2_member 74.33g used, 0 free 
{2koqPs-U1IA-9erV-ua4N-mxW1-BhRs-V3mlAH}
.   .VG RAID1 74.33g 0 free {HEGjco-Ptil-M5ZG-2qQR-zNo4-3cc5-b9Z3Kj}
.    .dm-0 9.77g [253:0] LV xenhost ext4 
{d2fa50d5-1a51-4599-9b72-f38f86b8f99e}
.    ..Mounted as /dev/mapper/RAID1-xenhost @ /
.    .dm-7 64.56g [253:7] LV zeus.vm ext4 
{67310780-b15c-47e4-812e-d954aa7d8e3b}
.scsi 1:0:0:0 ATA ST380815AS {6QZ6L9SD}
..sdb 74.53g [8:16] Partitioned (dos)
. .sdb1 200.00m [8:17] MD raid1 (0/2) (w/ sda1) in_sync 
'localhost.localdomain:0' {9f19116a-d280-8216-cc87-af34eae68242}
. ..md0 199.99m [9:0] MD v1.0 raid1 (2) clean
. .                   Partitioned (dos) 
{6578dbc0-9e07-4ccc-8eff-15f2a1da8df1}
. .sdb2 74.33g [8:18] MD raid1 (0/2) (w/ sda2) in_sync 
'localhost.localdomain:1' {afb92c19-b9b1-e3ae-07af-315d738e38be}
.  .md1 74.33g [9:1] MD v1.1 raid1 (2) clean
.                    PV LVM2_member 74.33g used, 0 free 
{2koqPs-U1IA-9erV-ua4N-mxW1-BhRs-V3mlAH}
.scsi 2:x:x:x [Empty]
.scsi 3:0:0:0 ATA ST2000VX000-9YW1 {Z1E10QQJ}
..sdc 1.82t [8:32] MD raid6 (3/4) (w/ sdd,sde,sdf) in_sync 
'xenhost.lan.crc.id.au:2' {cd8cc032-4898-fa88-3ba1-af64cf91583b}
. .md2 3.64t [9:2] MD v1.2 raid6,left-sym (4) active, 128k Chunk
.  .               PV LVM2_member 2.12t used, 1.52t free 
{8pyp2G-D268-fqKW-mBvf-wZbI-Qurt-aeTvOh}
.  .VG vg_raid6 3.64t 1.52t free {UrqTRc-AozJ-2RDf-qcZB-UdX3-tno9-3KHjjv}
.   .dm-6 2.00t [253:6] LV fileshare xfs 
{af405459-7569-4d82-82d9-ca27912316c7}
.   .dm-3 10.00g [253:3] LV lamp.vm ext4 
{67310780-b15c-47e4-812e-d954aa7d8e3b}
.   .dm-2 40.00g [253:2] LV mail.vm ext4 
{67310780-b15c-47e4-812e-d954aa7d8e3b}
.   .dm-4 20.00g [253:4] LV remotedesktop.vm Partitioned (dos)
.   .dm-5 2.00g [253:5] LV template.vm ext4 
{67310780-b15c-47e4-812e-d954aa7d8e3b}
.   .dm-1 50.00g [253:1] LV tsm.vm ext4 
{67310780-b15c-47e4-812e-d954aa7d8e3b}
.scsi 4:x:x:x [Empty]
.scsi 5:x:x:x [Empty]
PCI [sata_mv] 04:00.0 SCSI storage controller: Marvell Technology Group 
Ltd. 88SX7042 PCI-e 4-port SATA-II (rev 02)
.scsi 6:0:0:0 ATA ST2000VX000-9YW1 {Z1E11E7R}

..sdd 1.82t [8:48] MD raid6 (0/4) (w/ sdc,sde,sdf) in_sync 
'xenhost.lan.crc.id.au:2' {cd8cc032-4898-fa88-3ba1-af64cf91583b}
. .md2 3.64t [9:2] MD v1.2 raid6,left-sym (4) active, 128k Chunk
.                  PV LVM2_member 2.12t used, 1.52t free 
{8pyp2G-D268-fqKW-mBvf-wZbI-Qurt-aeTvOh}
.scsi 7:x:x:x [Empty]
.scsi 8:0:0:0 ATA ST2000VX000-9YW1 {Z1E0MD58}
..sde 1.82t [8:64] MD raid6 (1/4) (w/ sdc,sdd,sdf) in_sync 
'xenhost.lan.crc.id.au:2' {cd8cc032-4898-fa88-3ba1-af64cf91583b}
. .md2 3.64t [9:2] MD v1.2 raid6,left-sym (4) active, 128k Chunk
.                  PV LVM2_member 2.12t used, 1.52t free 
{8pyp2G-D268-fqKW-mBvf-wZbI-Qurt-aeTvOh}
.scsi 9:0:0:0 ATA ST2000VX000-9YW1 {Z1E17C3X}
  .sdf 1.82t [8:80] MD raid6 (2/4) (w/ sdc,sdd,sde) in_sync 
'xenhost.lan.crc.id.au:2' {cd8cc032-4898-fa88-3ba1-af64cf91583b}
   .md2 3.64t [9:2] MD v1.2 raid6,left-sym (4) active, 128k Chunk
                    PV LVM2_member 2.12t used, 1.52t free 
{8pyp2G-D268-fqKW-mBvf-wZbI-Qurt-aeTvOh}

I'm going to leave it as is at the moment to see if it happens again as 
it has been randomly over the last 3-4 weeks. I'll try to pull any info 
off this time before rebooting the system - as I only recently found 
this problem. Hopefully, either changing the slot, or even just 
reseating the card may have had some effect - but I guess only time will 
tell.

-- 
Steven Haigh

Email: netwiz@crc.id.au
Web: http://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
Fax: (03) 8338 0299




[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4965 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

  reply	other threads:[~2013-01-16 10:13 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-15  3:27 Kernel 3.7.[12] - irq 16: nobody cared Steven Haigh
2013-01-15 15:23 ` Jan Beulich
2013-01-15 17:15   ` Steven Haigh
2013-01-16  9:42     ` Jan Beulich
2013-01-16  9:54       ` Steven Haigh
2013-01-16 10:05         ` Jan Beulich
2013-01-16 10:13           ` Steven Haigh [this message]
  -- strict thread matches above, loose matches on Subject: below --
2013-01-14 23:16 Steven Haigh

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=50F67D37.3020008@crc.id.au \
    --to=netwiz@crc.id.au \
    --cc=JBeulich@suse.com \
    --cc=xen-devel@lists.xen.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 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.