LinuxLists.cc - regression: 100% io-wait with 2.6.24-rcX

2008-01-07 11:10:27

Subject: regression: 100% io-wait with 2.6.24-rcX

Hi,

when booting kernel 2.6.24-rc{4,5,6,7} top reports up to 100% iowait, even if
no program accesses the disc on my Thinkpad T40p. Kernel 2.6.23.12 does not
suffer from this. Is there anything I can do to find out which process or
which part of the kernel is responsible for this? I can try to bisect it, but
maybe there are other possibilities to debug this, since I cannot boot this
computer frequently. I discovered, that there is no iowait within the first
few seconds after waking up from suspend to ram...

regards,
Jörg

2008-01-07 11:19:48

by Ingo Molnar

[permalink] [raw]

Subject: Re: regression: 100% io-wait with 2.6.24-rcX

* Joerg Platte <[email protected]> wrote:

> Hi,
>
> when booting kernel 2.6.24-rc{4,5,6,7} top reports up to 100% iowait,
> even if no program accesses the disc on my Thinkpad T40p. Kernel
> 2.6.23.12 does not suffer from this. Is there anything I can do to
> find out which process or which part of the kernel is responsible for
> this? I can try to bisect it, but maybe there are other possibilities
> to debug this, since I cannot boot this computer frequently. I
> discovered, that there is no iowait within the first few seconds after
> waking up from suspend to ram...

do:

echo t > /proc/sysrq-trigger

and send us the dmesg output. If the dmesg output does not include the
bootup bits then increase CONFIG_LOG_BUF_SHIFT to 20 or so:

CONFIG_LOG_BUF_SHIFT=20

to have a large enough kernel messages buffer.

Ingo

2008-01-07 13:24:26

Am Mittwoch, 9. Januar 2008 schrieb Fengguang Wu:

Thank your for the hint with the filesystems!

> Thank you for the clue. However I cannot reproduce the bug on
> ext2/2.6.24-rc7. Can you provide more details? Thank you.

I attached some more information. I'm using the ata_piix driver for my PATA
disk and cdrom drive and booted with hpet=force. Kernel 2.6.23.X has been
patched with the -hrt patches to enable the hidden hpet time on the ICH4-M
chipset. I just rebooted the notebook and mounted /tmp again as ext2 and now
the iowait problem is back. Seems to be reproducible on my computer. What
additional information do you need?

regards,
J?rg

--
PGP Key: send mail with subject 'SEND PGP-KEY' PGP Key-ID: FD 4E 21 1D
PGP Fingerprint: 388A872AFC5649D3 BCEC65778BE0C605

Attachments:

(No filename) (783.00 B)
lspci (1.58 kB)
lsmod (7.30 kB)
dmesg (15.12 kB)
Download all attachments

2008-01-09 12:57:23

by Wu Fengguang

[permalink] [raw]

Subject: Re: regression: 100% io-wait with 2.6.24-rcX

On Wed, Jan 09, 2008 at 01:22:33PM +0100, Joerg Platte wrote:
> Am Mittwoch, 9. Januar 2008 schrieb Fengguang Wu:
>
> Thank your for the hint with the filesystems!
>
> > Thank you for the clue. However I cannot reproduce the bug on
> > ext2/2.6.24-rc7. Can you provide more details? Thank you.
>
> I attached some more information. I'm using the ata_piix driver for my PATA
> disk and cdrom drive and booted with hpet=force. Kernel 2.6.23.X has been
~~~~~~~~
not 2.6.24-rc7?

> patched with the -hrt patches to enable the hidden hpet time on the ICH4-M
> chipset. I just rebooted the notebook and mounted /tmp again as ext2 and now
> the iowait problem is back. Seems to be reproducible on my computer. What
> additional information do you need?

I mounted an ext2 as tmp and find no problem. My config options are:

CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT2_FS_SECURITY=y
# CONFIG_EXT2_FS_XIP is not set

Fengguang

2008-01-09 13:04:41

by Joerg Platte

[permalink] [raw]

Subject: Re: regression: 100% io-wait with 2.6.24-rcX

Am Mittwoch, 9. Januar 2008 schrieb Fengguang Wu:
> On Wed, Jan 09, 2008 at 01:22:33PM +0100, Joerg Platte wrote:
> > Am Mittwoch, 9. Januar 2008 schrieb Fengguang Wu:
> >
> > Thank your for the hint with the filesystems!
> >
> > > Thank you for the clue. However I cannot reproduce the bug on
> > > ext2/2.6.24-rc7. Can you provide more details? Thank you.
> >
> > I attached some more information. I'm using the ata_piix driver for my
> > PATA disk and cdrom drive and booted with hpet=force. Kernel 2.6.23.X has
> > been
>
> ~~~~~~~~
> not 2.6.24-rc7?
>
No, 2.6.23.X was the last working kernel without this problem, the bug shows
up with 2.6.24-rcX. I just wanted to emphasis, that I don't think that it has
something to do with the hpet stuff. Kernel 2.6.24-rcX is unpatched, because
the hrt stuff has been merged.

> > patched with the -hrt patches to enable the hidden hpet time on the
> > ICH4-M chipset. I just rebooted the notebook and mounted /tmp again as
> > ext2 and now the iowait problem is back. Seems to be reproducible on my
> > computer. What additional information do you need?
>
> I mounted an ext2 as tmp and find no problem. My config options are:
>
> CONFIG_EXT2_FS=y
> CONFIG_EXT2_FS_XATTR=y
> CONFIG_EXT2_FS_POSIX_ACL=y
> CONFIG_EXT2_FS_SECURITY=y
> # CONFIG_EXT2_FS_XIP is not set
>
> Fengguang

CONFIG_EXT2_FS=m
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT2_FS_SECURITY=y
CONFIG_EXT2_FS_XIP=y

Here it is modular and I enabled CONFIG_EXT2_FS_XIP, but the same is enabled
on 2.6.23.X. Maybe it is related to libata? I additionally discovered, that
the problem disappears for a few seconds when I press the eject button for
the ultra bay of my thinkpad. Pressing the button unregisters the cdrom drive
to be able to replace it with a hard drive or a battery. Maybe this bug is
thinkpad relared?

regards,
J?rg

--
PGP Key: send mail with subject 'SEND PGP-KEY' PGP Key-ID: FD 4E 21 1D
PGP Fingerprint: 388A872AFC5649D3 BCEC65778BE0C605

2008-01-10 06:58:30

by Wu Fengguang

[permalink] [raw]

Subject: Re: regression: 100% io-wait with 2.6.24-rcX

On Wed, Jan 09, 2008 at 02:04:29PM +0100, Joerg Platte wrote:
> Am Mittwoch, 9. Januar 2008 schrieb Fengguang Wu:
> > On Wed, Jan 09, 2008 at 01:22:33PM +0100, Joerg Platte wrote:
> > > Am Mittwoch, 9. Januar 2008 schrieb Fengguang Wu:
> > >
> > > Thank your for the hint with the filesystems!
> > >
> > > > Thank you for the clue. However I cannot reproduce the bug on
> > > > ext2/2.6.24-rc7. Can you provide more details? Thank you.
> > >
> > > I attached some more information. I'm using the ata_piix driver for my
> > > PATA disk and cdrom drive and booted with hpet=force. Kernel 2.6.23.X has
> > > been
> >
> > ~~~~~~~~
> > not 2.6.24-rc7?
> >
> No, 2.6.23.X was the last working kernel without this problem, the bug shows
> up with 2.6.24-rcX. I just wanted to emphasis, that I don't think that it has
> something to do with the hpet stuff. Kernel 2.6.24-rcX is unpatched, because
> the hrt stuff has been merged.
>
> > > patched with the -hrt patches to enable the hidden hpet time on the
> > > ICH4-M chipset. I just rebooted the notebook and mounted /tmp again as
> > > ext2 and now the iowait problem is back. Seems to be reproducible on my
> > > computer. What additional information do you need?
> >
> > I mounted an ext2 as tmp and find no problem. My config options are:
> >
> > CONFIG_EXT2_FS=y
> > CONFIG_EXT2_FS_XATTR=y
> > CONFIG_EXT2_FS_POSIX_ACL=y
> > CONFIG_EXT2_FS_SECURITY=y
> > # CONFIG_EXT2_FS_XIP is not set
> >
> > Fengguang
>
> CONFIG_EXT2_FS=m
> CONFIG_EXT2_FS_XATTR=y
> CONFIG_EXT2_FS_POSIX_ACL=y
> CONFIG_EXT2_FS_SECURITY=y
> CONFIG_EXT2_FS_XIP=y
>
> Here it is modular and I enabled CONFIG_EXT2_FS_XIP, but the same is enabled
> on 2.6.23.X. Maybe it is related to libata? I additionally discovered, that
> the problem disappears for a few seconds when I press the eject button for
> the ultra bay of my thinkpad. Pressing the button unregisters the cdrom drive
> to be able to replace it with a hard drive or a battery. Maybe this bug is
> thinkpad relared?

At last I caught it :-)

[ 1862.219189] requeue_io 301: inode 50948 size 0 at 03:02(hda2)
[ 1862.219199] requeue_io 301: inode 51616 size 0 at 03:02(hda2)
[ 1862.219204] requeue_io 301: inode 51656 size 0 at 03:02(hda2)
[ 1862.219208] requeue_io 301: inode 51655 size 0 at 03:02(hda2)
[ 1862.219216] mm/page-writeback.c 668 wb_kupdate: pdflush(182) 10768 global 3100 0 0 wc _M tw 1024 sk 1
[ 1862.319039] requeue_io 301: inode 50948 size 0 at 03:02(hda2)
[ 1862.319050] requeue_io 301: inode 51616 size 0 at 03:02(hda2)
[ 1862.319055] requeue_io 301: inode 51656 size 0 at 03:02(hda2)
[ 1862.319059] requeue_io 301: inode 51655 size 0 at 03:02(hda2)
[ 1862.319068] mm/page-writeback.c 668 wb_kupdate: pdflush(182) 10768 global 3100 0 0 wc _M tw 1024 sk 1

They are some zero sized files, maybe something goes wrong with the truncate code.

2008-01-10 07:31:10

On Sun, Jan 13, 2008 at 12:32:30AM +0100, Joerg Platte wrote:
> Am Freitag, 11. Januar 2008 schrieb Fengguang Wu:
> > On Thu, Jan 10, 2008 at 11:03:05AM +0100, Joerg Platte wrote:
> > > Am Donnerstag, 10. Januar 2008 schrieb Fengguang Wu:
> > > > > problem, because the iowait problem disappeared today after the
> > > > > regular Debian update. I'll try to install the old package versions
> > > > > to make it show up again. Maybe that helps to debug it.
> > > >
> > > > Thank you. I'm running sid, ext2 as rootfs now ;-)
> > >
> > > The error is back and I'm getting thousands of messages like this with
> > > the patched kernel:
> > >
> > > mm/page-writeback.c 668 wb_kupdate: pdflush(146) 21115 global 3936 0 0 wc
> > > _M > tw 1024 sk 0 requeue_io 301: inode 81441 size 0 at 08:07(sda7)
> > > mm/page-writeback.c 668 wb_kupdate: pdflush(147) 17451 global 3936 0 0 wc
> > > _M > tw 1024 sk 2 requeue_io 301: inode 81441 size 0 at 08:07(sda7)
> > > mm/page-writeback.c 668 wb_kupdate: pdflush(147) 17451 global 3936 0 0 wc
> > > _M > tw 1024 sk 2 requeue_io 301: inode 81441 size 0 at 08:07(sda7)
> >
> > Joerg, what's the output of `dumpe2fs /dev/sda7` and `lsof|grep /tmp`?
>
> After another reboot I tried to get more information about the konqueror
> process possibly causing the iowait load by using strace -p. Here is the
> output:
>
> gettimeofday({1200180588, 878508}, NULL) = 0
> setitimer(ITIMER_VIRTUAL, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0
> rt_sigaction(SIGVTALRM, {SIG_DFL}, {0xb5cffed0, [VTALRM], SA_RESTART}, 8) = 0
> gettimeofday({1200180588, 879942}, NULL) = 0
> time(NULL) = 1200180588
> gettimeofday({1200180588, 880838}, NULL) = 0
> gettimeofday({1200180588, 881284}, NULL) = 0

No idea yet :-/ I'm afraid I have to trouble you again - the bug just
refused to appear in my system. I prepared a kernel module for you to
gather more information:

make && insmod ext2-writeback-debug.ko && sleep 1s && rmmod ext2-writeback-debug
dmesg > ext2-writeback-debug.dmesg

Please do it when 100% iowait appears, and send the dmesg file.

Thank you,
Fengguang

Attachments:

(No filename) (2.07 kB)
Makefile (187.00 B)
ext2-writeback-debug.c (3.52 kB)
Download all attachments

2008-01-13 08:05:59

by Joerg Platte

[permalink] [raw]

Subject: Re: regression: 100% io-wait with 2.6.24-rcX

Am Sonntag, 13. Januar 2008 schrieb Fengguang Wu:

> No idea yet :-/ I'm afraid I have to trouble you again - the bug just
> refused to appear in my system. I prepared a kernel module for you to
> gather more information:

> make && insmod ext2-writeback-debug.ko && sleep 1s && rmmod
> ext2-writeback-debug dmesg > ext2-writeback-debug.dmesg

Unfortunately, I unable to compile the module:

make -C /lib/modules/2.6.24-rc7-ext2/build SUBDIRS=/export/src modules
make[1]: Entering directory `/export/src/linux-2.6.24-rc7'
CC [M] /export/src/ext2-writeback-debug.o
/export/src/ext2-writeback-debug.c:89: error: variable ‘my_kprobe’ has
initializer but incomplete type
/export/src/ext2-writeback-debug.c:90: error: unknown field ‘pre_handler’
specified in initializer
/export/src/ext2-writeback-debug.c:90: warning: excess elements in struct
initializer
/export/src/ext2-writeback-debug.c:90: warning: (near initialization
for ‘my_kprobe’)
/export/src/ext2-writeback-debug.c:91: error: unknown field ‘post_handler’
specified in initializer
/export/src/ext2-writeback-debug.c:91: warning: excess elements in struct
initializer
/export/src/ext2-writeback-debug.c:91: warning: (near initialization
for ‘my_kprobe’)
/export/src/ext2-writeback-debug.c:92: error: unknown field ‘symbol_name’
specified in initializer
/export/src/ext2-writeback-debug.c:93: warning: excess elements in struct
initializer
/export/src/ext2-writeback-debug.c:93: warning: (near initialization
for ‘my_kprobe’)
/export/src/ext2-writeback-debug.c:109: error:
variable ‘jprobe_ext2_writepage’ has initializer but incomplete type
/export/src/ext2-writeback-debug.c:110: error: unknown field ‘entry’ specified
in initializer
/export/src/ext2-writeback-debug.c:110: warning: excess elements in struct
initializer
/export/src/ext2-writeback-debug.c:110: warning: (near initialization
for ‘jprobe_ext2_writepage’)
/export/src/ext2-writeback-debug.c:111: error: unknown field ‘kp’ specified in
initializer
/export/src/ext2-writeback-debug.c:112: warning: excess elements in struct
initializer
/export/src/ext2-writeback-debug.c:112: warning: (near initialization
for ‘jprobe_ext2_writepage’)
/export/src/ext2-writeback-debug.c:124: error: variable ‘jprobe_requeue_io’
has initializer but incomplete type
/export/src/ext2-writeback-debug.c:125: error: unknown field ‘entry’ specified
in initializer
/export/src/ext2-writeback-debug.c:125: warning: excess elements in struct
initializer
/export/src/ext2-writeback-debug.c:125: warning: (near initialization
for ‘jprobe_requeue_io’)
/export/src/ext2-writeback-debug.c:126: error: unknown field ‘kp’ specified in
initializer
/export/src/ext2-writeback-debug.c:127: warning: excess elements in struct
initializer
/export/src/ext2-writeback-debug.c:127: warning: (near initialization
for ‘jprobe_requeue_io’)
/export/src/ext2-writeback-debug.c: In function ‘setup_kprobe’:
/export/src/ext2-writeback-debug.c:132: error: dereferencing pointer to
incomplete type
/export/src/ext2-writeback-debug.c: In function ‘setup_jprobe’:
/export/src/ext2-writeback-debug.c:139: error: dereferencing pointer to
incomplete type
make[2]: *** [/export/src/ext2-writeback-debug.o] Error 1
make[1]: *** [_module_/export/src] Error 2
make[1]: Leaving directory `/export/src/linux-2.6.24-rc7'
make: *** [default] Error 2

regards,
Jörg

--
PGP Key: send mail with subject 'SEND PGP-KEY' PGP Key-ID: FD 4E 21 1D
PGP Fingerprint: 388A872AFC5649D3 BCEC65778BE0C605

2008-01-13 08:21:39

by Wu Fengguang

[permalink] [raw]

Subject: Re: regression: 100% io-wait with 2.6.24-rcX

On Sun, Jan 13, 2008 at 09:05:43AM +0100, Joerg Platte wrote:
> Am Sonntag, 13. Januar 2008 schrieb Fengguang Wu:
>
> > No idea yet :-/ I'm afraid I have to trouble you again - the bug just
> > refused to appear in my system. I prepared a kernel module for you to
> > gather more information:
>
> > make && insmod ext2-writeback-debug.ko && sleep 1s && rmmod
> > ext2-writeback-debug dmesg > ext2-writeback-debug.dmesg
>
> Unfortunately, I unable to compile the module:

> make -C /lib/modules/2.6.24-rc7-ext2/build SUBDIRS=/export/src modules
> make[1]: Entering directory `/export/src/linux-2.6.24-rc7'
> CC [M] /export/src/ext2-writeback-debug.o
> /export/src/ext2-writeback-debug.c:89: error: variable ‘my_kprobe’ has
> initializer but incomplete type

Do you have CONFIG_KPROBES=y?

2008-01-13 09:49:55

> On Jan 16, 2008 9:15 AM, Martin Knoblauch <[email protected]> wrote:
> Fengguang's latest writeback patch applies cleanly, builds, boots on 2.6.24-rc8.

Linus, if possible, I'd suggest this patch be merged for 2.6.24.

It's a safer version of the reverted patch. It was tested on
ext2/ext3/jfs/xfs/reiserfs and won't 100% iowait even without the
other bug fixing patches.

Fengguang
---

writeback: speed up writeback of big dirty files

After making dirty a 100M file, the normal behavior is to
start the writeback for all data after 30s delays. But
sometimes the following happens instead:

- after 30s: ~4M
- after 5s: ~4M
- after 5s: all remaining 92M

Some analyze shows that the internal io dispatch queues goes like this:

s_io s_more_io
-------------------------
1) 100M,1K 0
2) 1K 96M
3) 0 96M
1) initial state with a 100M file and a 1K file
2) 4M written, nr_to_write <= 0, so write more
3) 1K written, nr_to_write > 0, no more writes(BUG)
nr_to_write > 0 in (3) fools the upper layer to think that data have all been
written out. The big dirty file is actually still sitting in s_more_io. We
cannot simply splice s_more_io back to s_io as soon as s_io becomes empty, and
let the loop in generic_sync_sb_inodes() continue: this may starve newly
expired inodes in s_dirty. It is also not an option to draw inodes from both
s_more_io and s_dirty, an let the loop go on: this might lead to live locks,
and might also starve other superblocks in sync time(well kupdate may still
starve some superblocks, that's another bug).
We have to return when a full scan of s_io completes. So nr_to_write > 0 does
not necessarily mean that "all data are written". This patch introduces a flag
writeback_control.more_io to indicate that more io should be done. With it the
big dirty file no longer has to wait for the next kupdate invocation 5s later.

In sync_sb_inodes() we only set more_io on super_blocks we actually visited.
This aviods the interaction between two pdflush deamons.

Also in __sync_single_inode() we don't blindly keep requeuing the io if the
filesystem cannot progress. Failing to do so may lead to 100% iowait.

Tested-by: Mike Snitzer <[email protected]>
Signed-off-by: Fengguang Wu <[email protected]>
---
fs/fs-writeback.c | 18 ++++++++++++++++--
include/linux/writeback.h | 1 +
mm/page-writeback.c | 9 ++++++---
3 files changed, 23 insertions(+), 5 deletions(-)

--- linux.orig/fs/fs-writeback.c
+++ linux/fs/fs-writeback.c
@@ -284,7 +284,17 @@ __sync_single_inode(struct inode *inode,
* soon as the queue becomes uncongested.
*/
inode->i_state |= I_DIRTY_PAGES;
- requeue_io(inode);
+ if (wbc->nr_to_write <= 0) {
+ /*
+ * slice used up: queue for next turn
+ */
+ requeue_io(inode);
+ } else {
+ /*
+ * somehow blocked: retry later
+ */
+ redirty_tail(inode);
+ }
} else {
/*
* Otherwise fully redirty the inode so that
@@ -479,8 +489,12 @@ sync_sb_inodes(struct super_block *sb, s
iput(inode);
cond_resched();
spin_lock(&inode_lock);
- if (wbc->nr_to_write <= 0)
+ if (wbc->nr_to_write <= 0) {
+ wbc->more_io = 1;
break;
+ }
+ if (!list_empty(&sb->s_more_io))
+ wbc->more_io = 1;
}
return; /* Leave any unwritten inodes on s_io */
}
--- linux.orig/include/linux/writeback.h
+++ linux/include/linux/writeback.h
@@ -62,6 +62,7 @@ struct writeback_control {
unsigned for_reclaim:1; /* Invoked from the page allocator */
unsigned for_writepages:1; /* This is a writepages() call */
unsigned range_cyclic:1; /* range_start is cyclic */
+ unsigned more_io:1; /* more io to be dispatched */
};

/*
--- linux.orig/mm/page-writeback.c
+++ linux/mm/page-writeback.c
@@ -558,6 +558,7 @@ static void background_writeout(unsigned
global_page_state(NR_UNSTABLE_NFS) < background_thresh
&& min_pages <= 0)
break;
+ wbc.more_io = 0;
wbc.encountered_congestion = 0;
wbc.nr_to_write = MAX_WRITEBACK_PAGES;
wbc.pages_skipped = 0;
@@ -565,8 +566,9 @@ static void background_writeout(unsigned
min_pages -= MAX_WRITEBACK_PAGES - wbc.nr_to_write;
if (wbc.nr_to_write > 0 || wbc.pages_skipped > 0) {
/* Wrote less than expected */
- congestion_wait(WRITE, HZ/10);
- if (!wbc.encountered_congestion)
+ if (wbc.encountered_congestion || wbc.more_io)
+ congestion_wait(WRITE, HZ/10);
+ else
break;
}
}
@@ -631,11 +633,12 @@ static void wb_kupdate(unsigned long arg
global_page_state(NR_UNSTABLE_NFS) +
(inodes_stat.nr_inodes - inodes_stat.nr_unused);
while (nr_to_write > 0) {
+ wbc.more_io = 0;
wbc.encountered_congestion = 0;
wbc.nr_to_write = MAX_WRITEBACK_PAGES;
writeback_inodes(&wbc);
if (wbc.nr_to_write > 0) {
- if (wbc.encountered_congestion)
+ if (wbc.encountered_congestion || wbc.more_io)
congestion_wait(WRITE, HZ/10);
else
break; /* All the old data is written */

2008-01-17 13:53:18

by Martin Knoblauch

[permalink] [raw]

On Tue, Jan 22, 2008 at 07:25:15AM -0800, Martin Knoblauch wrote:
> [root@lpsdm52 ~]# dmsetup table
> VolGroup00-LogVol02: 0 350945280 linear 104:2 67109248
> VolGroup00-LogVol01: 0 8388608 linear 104:2 418054528
> VolGroup00-LogVol00: 0 67108864 linear 104:2 384

The IO should pass straight through simple linear targets like that without
needing to get broken up, so I wouldn't expect those patches to make any
difference in this particular case.

Alasdair
--
[email protected]

2008-01-23 11:12:53

by Martin Knoblauch

[permalink] [raw]

Subject: Re: regression: 100% io-wait with 2.6.24-rcX

----- Original Message ----
> From: Alasdair G Kergon <[email protected]>
> To: Martin Knoblauch <[email protected]>
> Cc: Linus Torvalds <[email protected]>; Mel Gorman <[email protected]>; Fengguang Wu <[email protected]>; Mike Snitzer <[email protected]>; Peter Zijlstra <[email protected]>; [email protected]; Ingo Molnar <[email protected]>; [email protected]; "[email protected]" <[email protected]>; [email protected]; Jens Axboe <[email protected]>; Milan Broz <[email protected]>; Neil Brown <[email protected]>
> Sent: Wednesday, January 23, 2008 12:40:52 AM
> Subject: Re: regression: 100% io-wait with 2.6.24-rcX
>
> On Tue, Jan 22, 2008 at 07:25:15AM -0800, Martin Knoblauch wrote:
> > [root@lpsdm52 ~]# dmsetup table
> > VolGroup00-LogVol02: 0 350945280 linear 104:2 67109248
> > VolGroup00-LogVol01: 0 8388608 linear 104:2 418054528
> > VolGroup00-LogVol00: 0 67108864 linear 104:2 384
>
> The IO should pass straight through simple linear targets like
> that without needing to get broken up, so I wouldn't expect those patches to
> make any difference in this particular case.
>

Alasdair,

LVM/DM are off the hook :-) I converted one box to direct using partitions and the performance is the same disappointment as with LVM/DM. Thanks anyway for looking at my problem.

I will move the discussion now to a new thread, targetting CCISS directly.

Cheers
Martin