Re: pdflush stuck in D state with v2.6.24-rc1-192-gef49c32

[Florin Iucha <florin@iucha.net>]

[-- Attachment #1: Type: text/plain, Size: 1543 bytes --]

On Fri, Nov 02, 2007 at 08:56:55PM +0800, Fengguang Wu wrote:
> > > ---
> > >  fs/reiserfs/stree.c |    3 ---
> > >  1 file changed, 3 deletions(-)
> > > 
> > > --- linux-2.6.24-git17.orig/fs/reiserfs/stree.c
> > > +++ linux-2.6.24-git17/fs/reiserfs/stree.c
> > > @@ -1458,9 +1458,6 @@ static void unmap_buffers(struct page *p
> > >  				}
> > >  				bh = next;
> > >  			} while (bh != head);
> > > -			if (PAGE_SIZE == bh->b_size) {
> > > -				cancel_dirty_page(page, PAGE_CACHE_SIZE);
> > > -			}
> > >  		}
> > >  	}
> > >  }
> > 
> > ... and with the above patch applied.
> > 
> > Copying 300 MB from root (ext3) to the new file system did not trigger
> > the pdflush condition.  But then I did a
> >    cd $MOUNTPOINT && find . -exec md5sum {} \;
> > and that brought one cpu to 75% iowait.
> 
> Immediately? Do you have the debug printk messages this time(with the
> above patch)?

No, but I will add them this afternoon.

> > I have attached my .config, if it helps.
> 
> It's really curious - I tried your .config and commands, and still
> could not trigger the high iowait. I'm running 64bit Intel Core 2,
> and kernel 2.6.24-rc1-git6 with the above patch.

Curious but 100% reproducible, at least on my box.  What I'm going to
try is booting into the kernel with your patch and just doing the find
/ md5sum.  It would be really interesting if the read-only access
triggers it.

florin

-- 
Bruce Schneier expects the Spanish Inquisition.
      http://geekz.co.uk/schneierfacts/fact/163

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]