From: Hironobu Ishii <ishii.hironobu@jp.fujitsu.com>
To: linux-kernel <linux-kernel@vger.kernel.org>,
linux-ia64 <linux-ia64@vger.kernel.org>
Subject: [RFC/PATCH, 1/4] readX_check() performance evaluation
Date: Wed, 28 Jan 2004 01:54:28 +0000 [thread overview]
Message-ID: <00a201c3e541$c0e7d680$2987110a@lsd.css.fujitsu.com> (raw)
Hi all,
We are planning recovery from the PCI bus intermittent errors.
PCI-X standard describes it as "5.4 Error Handling and Fault
Tolerance" in PCI-X 1.0b. There were several discussions in lkml,
how to recover from PCI errors.
Seto posted "[RFC] How drivers notice a HW error?" (readX_check() I/F)
http://marc.theaimsgroup.com/?l=linux-kernel&m\x106992207709400&w=2
Grant will show his idea near future,
http://marc.theaimsgroup.com/?l=linux-kernel&m\x107453681120603&w=2
I made a readX_check() prototype which Seto proposed to measure
performance disadvantage of this kind of I/F. And I made a performance
evaluation of Disk I/O with this prototype.
Comments are welcome.
Conclusion:
Performance disadvantage of readX_check() is a very small.
I'd like you to understand that such a function will not
cause severe performance disadvantage as you imagine.
This patch:
- is for Fusion MPT driver.
- has no error recovery code yet, sorry.
- currently supports ia64 only. But I believe that
some other CPU(such as SPARC, PPC, PA-RISC) can also
support this kind of I/F.
I know, unfortunately, that i386 can't support this kind
of I/F, because it can't recover from machine check state.
How to use this patch:
- Apply to vanilla 2.6.1.
- Rename drivers/message/fusion/mptbase.c to mptbase_main.c
(Because we make mptbase.ko from mptbase.c and read_check.S,
so source file name has to be renamed. Though I know
read_check.S should go under the architecture directory,
because this patch is only for performance evaluation,
forgive me. )
Evaluation Environment:
Kernel:
vanilla 2.6.1 and 2.6.1+readX_check patch
Platform: Intel Tiger-4 (1-CPU)
processor : 0
vendor : GenuineIntel
arch : IA-64
family : Itanium 2
model : 1
revision : 5
archrev : 0
features : branchlong
cpu number : 0
cpu regs : 4
cpu MHz : 1296.473997
itc MHz : 1296.473997
BogoMIPS : 1941.96
SCSI HBA/driver:
onboard LSI Logic 53C1030(FwRev\x01030600h, MaxQ%5)
Fusion MPT driver(kernel 2.6.1)
Disks
Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: FUJITSU Model: MAP3367NC Rev: 5207
Type: Direct-Access ANSI SCSI revision: 03
Host: scsi0 Channel: 00 Id: 01 Lun: 00
Vendor: FUJITSU Model: MAP3367NC Rev: 5207
Type: Direct-Access ANSI SCSI revision: 03
Host: scsi0 Channel: 00 Id: 02 Lun: 00
Vendor: FUJITSU Model: MAP3367NC Rev: 5207
Type: Direct-Access ANSI SCSI revision: 03
Test tool:
rawread 1.0.3
http://www-124.ibm.com/developerworks/opensource/linuxperf/rawread/rawread.html
Results:
To avoid buffer cache, we measured performance by O_DIRECT.
1-1) ./rawread -p 1 -d 1 -s 512 -n 131072 -x -z
(1 disk, 512-bytes/1-read,)
avg. sys(%)
MB/s IOPS of vmstat
---------------------------------------------------
patched 2.6.1 5.245 10741 16.2
vanilla 2.6.1 5.269 10790 15.7
---------------------------------------------------
patched/vanilla 0.995 1.032
1-2) ./rawread -p 2 -d 1 -s 512 -n 131072 -x -z
(2 disks, 512-bytes/1-read,)
avg. sys(%)
MB/s IOPS of vmstat
---------------------------------------------------
patched 2.6.1 10.473 21448 30.6
vanilla 2.6.1 10.548 21602 30.6
---------------------------------------------------
patched/vanilla 0.993 1.000
1-3) ./rawread -p 3 -d 1 -s 512 -n 131072 -x -z
(3 disks, 512-bytes/1-read,)
avg. sys(%)
MB/s IOPS of vmstat
---------------------------------------------------
patched 2.6.1 11.267 23074 29.9
vanilla 2.6.1 11.251 23042 30.5
---------------------------------------------------
patched/vanilla 1.001 0.980
2-1) ./rawread -p 1 -d 1 -s 4096 -n 131072 -x -z
(1 disk, 4096-bytes/1-read,)
avg. sys(%)
MB/s IOPS of vmstat
---------------------------------------------------
patched 2.6.1 39.422 10092 14.1
vanilla 2.6.1 39.389 10083 14.0
---------------------------------------------------
patched/vanilla 1.001 1.007
2-2) ./rawread -p 2 -d 1 -s 4096 -n 131072 -x -z
(2 disks, 4096-bytes/1-read,)
avg. sys(%)
MB/s IOPS of vmstat
---------------------------------------------------
patched 2.6.1 70.438 18032 24.1
vanilla 2.6.1 70.390 18019 24.1
---------------------------------------------------
patched/vanilla 1.001 1.000
2-3) ./rawread -p 3 -d 1 -s 4096 -n 131072 -x -z
(3 disks, 4096-bytes/1-read,)
avg. sys(%)
MB/s IOPS of vmstat
---------------------------------------------------
patched 2.6.1 70.588 18070 24.5
vanilla 2.6.1 70.861 18140 24.4
---------------------------------------------------
patched/vanilla 0.996 1.004
3-1) ./rawread -p 1 -d 1 -s 32768 -n 131072 -x -z
(1 disk, 32768-bytes/1-read,)
avg. sys(%)
MB/s IOPS of vmstat
---------------------------------------------------
patched 2.6.1 69.226 2215 3.5
vanilla 2.6.1 68.546 2190 3.4
---------------------------------------------------
patched/vanilla 1.010 1.029
3-2) ./rawread -p 2 -d 1 -s 32768 -n 131072 -x -z
(2 disk, 32768-bytes/1-read,)
avg. sys(%)
MB/s IOPS of vmstat
---------------------------------------------------
patched 2.6.1 139.315 4458 7.0
vanilla 2.6.1 139.188 4454 6.6
---------------------------------------------------
patched/vanilla 1.010 1.029
3-3) ./rawread -p 3 -d 1 -s 32768 -n 131072 -x -z
(3 disks, 32768-bytes/1-read,)
avg. sys(%)
MB/s IOPS of vmstat
---------------------------------------------------
patched 2.6.1 208.883 6684 10.0
vanilla 2.6.1 209.193 6694 10.2
---------------------------------------------------
patched/vanilla 0.999 0.980
-------
Thanks,
Hironobu Ishii
WARNING: multiple messages have this Message-ID (diff)
From: Hironobu Ishii <ishii.hironobu@jp.fujitsu.com>
To: linux-kernel <linux-kernel@vger.kernel.org>,
linux-ia64 <linux-ia64@vger.kernel.org>
Subject: [RFC/PATCH, 1/4] readX_check() performance evaluation
Date: Wed, 28 Jan 2004 10:54:28 +0900 [thread overview]
Message-ID: <00a201c3e541$c0e7d680$2987110a@lsd.css.fujitsu.com> (raw)
Hi all,
We are planning recovery from the PCI bus intermittent errors.
PCI-X standard describes it as "5.4 Error Handling and Fault
Tolerance" in PCI-X 1.0b. There were several discussions in lkml,
how to recover from PCI errors.
Seto posted "[RFC] How drivers notice a HW error?" (readX_check() I/F)
http://marc.theaimsgroup.com/?l=linux-kernel&m=106992207709400&w=2
Grant will show his idea near future,
http://marc.theaimsgroup.com/?l=linux-kernel&m=107453681120603&w=2
I made a readX_check() prototype which Seto proposed to measure
performance disadvantage of this kind of I/F. And I made a performance
evaluation of Disk I/O with this prototype.
Comments are welcome.
Conclusion:
Performance disadvantage of readX_check() is a very small.
I'd like you to understand that such a function will not
cause severe performance disadvantage as you imagine.
This patch:
- is for Fusion MPT driver.
- has no error recovery code yet, sorry.
- currently supports ia64 only. But I believe that
some other CPU(such as SPARC, PPC, PA-RISC) can also
support this kind of I/F.
I know, unfortunately, that i386 can't support this kind
of I/F, because it can't recover from machine check state.
How to use this patch:
- Apply to vanilla 2.6.1.
- Rename drivers/message/fusion/mptbase.c to mptbase_main.c
(Because we make mptbase.ko from mptbase.c and read_check.S,
so source file name has to be renamed. Though I know
read_check.S should go under the architecture directory,
because this patch is only for performance evaluation,
forgive me. )
Evaluation Environment:
Kernel:
vanilla 2.6.1 and 2.6.1+readX_check patch
Platform: Intel Tiger-4 (1-CPU)
processor : 0
vendor : GenuineIntel
arch : IA-64
family : Itanium 2
model : 1
revision : 5
archrev : 0
features : branchlong
cpu number : 0
cpu regs : 4
cpu MHz : 1296.473997
itc MHz : 1296.473997
BogoMIPS : 1941.96
SCSI HBA/driver:
onboard LSI Logic 53C1030(FwRev=01030600h, MaxQ=255)
Fusion MPT driver(kernel 2.6.1)
Disks
Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: FUJITSU Model: MAP3367NC Rev: 5207
Type: Direct-Access ANSI SCSI revision: 03
Host: scsi0 Channel: 00 Id: 01 Lun: 00
Vendor: FUJITSU Model: MAP3367NC Rev: 5207
Type: Direct-Access ANSI SCSI revision: 03
Host: scsi0 Channel: 00 Id: 02 Lun: 00
Vendor: FUJITSU Model: MAP3367NC Rev: 5207
Type: Direct-Access ANSI SCSI revision: 03
Test tool:
rawread 1.0.3
http://www-124.ibm.com/developerworks/opensource/linuxperf/rawread/rawread.html
Results:
To avoid buffer cache, we measured performance by O_DIRECT.
1-1) ./rawread -p 1 -d 1 -s 512 -n 131072 -x -z
(1 disk, 512-bytes/1-read,)
avg. sys(%)
MB/s IOPS of vmstat
---------------------------------------------------
patched 2.6.1 5.245 10741 16.2
vanilla 2.6.1 5.269 10790 15.7
---------------------------------------------------
patched/vanilla 0.995 1.032
1-2) ./rawread -p 2 -d 1 -s 512 -n 131072 -x -z
(2 disks, 512-bytes/1-read,)
avg. sys(%)
MB/s IOPS of vmstat
---------------------------------------------------
patched 2.6.1 10.473 21448 30.6
vanilla 2.6.1 10.548 21602 30.6
---------------------------------------------------
patched/vanilla 0.993 1.000
1-3) ./rawread -p 3 -d 1 -s 512 -n 131072 -x -z
(3 disks, 512-bytes/1-read,)
avg. sys(%)
MB/s IOPS of vmstat
---------------------------------------------------
patched 2.6.1 11.267 23074 29.9
vanilla 2.6.1 11.251 23042 30.5
---------------------------------------------------
patched/vanilla 1.001 0.980
2-1) ./rawread -p 1 -d 1 -s 4096 -n 131072 -x -z
(1 disk, 4096-bytes/1-read,)
avg. sys(%)
MB/s IOPS of vmstat
---------------------------------------------------
patched 2.6.1 39.422 10092 14.1
vanilla 2.6.1 39.389 10083 14.0
---------------------------------------------------
patched/vanilla 1.001 1.007
2-2) ./rawread -p 2 -d 1 -s 4096 -n 131072 -x -z
(2 disks, 4096-bytes/1-read,)
avg. sys(%)
MB/s IOPS of vmstat
---------------------------------------------------
patched 2.6.1 70.438 18032 24.1
vanilla 2.6.1 70.390 18019 24.1
---------------------------------------------------
patched/vanilla 1.001 1.000
2-3) ./rawread -p 3 -d 1 -s 4096 -n 131072 -x -z
(3 disks, 4096-bytes/1-read,)
avg. sys(%)
MB/s IOPS of vmstat
---------------------------------------------------
patched 2.6.1 70.588 18070 24.5
vanilla 2.6.1 70.861 18140 24.4
---------------------------------------------------
patched/vanilla 0.996 1.004
3-1) ./rawread -p 1 -d 1 -s 32768 -n 131072 -x -z
(1 disk, 32768-bytes/1-read,)
avg. sys(%)
MB/s IOPS of vmstat
---------------------------------------------------
patched 2.6.1 69.226 2215 3.5
vanilla 2.6.1 68.546 2190 3.4
---------------------------------------------------
patched/vanilla 1.010 1.029
3-2) ./rawread -p 2 -d 1 -s 32768 -n 131072 -x -z
(2 disk, 32768-bytes/1-read,)
avg. sys(%)
MB/s IOPS of vmstat
---------------------------------------------------
patched 2.6.1 139.315 4458 7.0
vanilla 2.6.1 139.188 4454 6.6
---------------------------------------------------
patched/vanilla 1.010 1.029
3-3) ./rawread -p 3 -d 1 -s 32768 -n 131072 -x -z
(3 disks, 32768-bytes/1-read,)
avg. sys(%)
MB/s IOPS of vmstat
---------------------------------------------------
patched 2.6.1 208.883 6684 10.0
vanilla 2.6.1 209.193 6694 10.2
---------------------------------------------------
patched/vanilla 0.999 0.980
-------
Thanks,
Hironobu Ishii
next reply other threads:[~2004-01-28 1:54 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-28 1:54 Hironobu Ishii [this message]
2004-01-28 1:54 ` [RFC/PATCH, 1/4] readX_check() performance evaluation Hironobu Ishii
2004-01-28 17:20 ` Grant Grundler
2004-01-28 17:20 ` Grant Grundler
2004-01-28 17:41 ` Andi Kleen
2004-01-28 17:41 ` Andi Kleen
2004-01-28 18:31 ` David Mosberger
2004-01-28 18:31 ` David Mosberger
2004-01-28 18:52 ` Andi Kleen
2004-01-28 18:52 ` Andi Kleen
2004-01-28 19:24 ` David Mosberger
2004-01-28 19:24 ` David Mosberger
2004-01-28 19:39 ` Andi Kleen
2004-01-28 19:39 ` Andi Kleen
2004-01-28 19:48 ` David Mosberger
2004-01-28 19:48 ` David Mosberger
2004-01-28 20:01 ` Andi Kleen
2004-01-28 20:01 ` Andi Kleen
2004-01-28 23:35 ` David Mosberger
2004-01-28 23:35 ` David Mosberger
2004-02-16 10:19 ` Pavel Machek
2004-02-16 10:19 ` Pavel Machek
2004-01-28 19:09 ` Grant Grundler
2004-01-28 19:09 ` Grant Grundler
2004-01-28 19:17 ` Andi Kleen
2004-01-28 19:17 ` Andi Kleen
2004-01-28 21:14 ` Grant Grundler
2004-01-28 21:14 ` Grant Grundler
2004-01-28 21:39 ` Andi Kleen
2004-01-28 21:39 ` Andi Kleen
2004-01-29 8:23 ` Matthias Fouquet-Lapar
2004-01-29 8:23 ` Matthias Fouquet-Lapar
2004-01-29 19:28 ` David Mosberger
2004-01-29 19:28 ` David Mosberger
2004-01-29 20:16 ` Matthias Fouquet-Lapar
2004-01-29 20:16 ` Matthias Fouquet-Lapar
2004-01-29 21:09 ` David Mosberger
2004-01-29 21:09 ` David Mosberger
2004-01-29 22:20 ` Matthias Fouquet-Lapar
2004-01-29 22:20 ` Matthias Fouquet-Lapar
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='00a201c3e541$c0e7d680$2987110a@lsd.css.fujitsu.com' \
--to=ishii.hironobu@jp.fujitsu.com \
--cc=linux-ia64@vger.kernel.org \
--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 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.