lkml.org 
[lkml]   [2007]   [Oct]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: pdflush stuck in D state with v2.6.24-rc1-192-gef49c32
On Wed, Oct 31, 2007 at 02:53:25PM +0800, Fengguang Wu wrote:
> On Tue, Oct 30, 2007 at 10:52:45PM -0500, Florin Iucha wrote:
> > On Tue, Oct 30, 2007 at 07:02:42PM -0500, Florin Iucha wrote:
> > > I have added the patches and started a linux kernel compilation, and
> > > something really interesting happens. I run the build with the
> > > equivalent of "make -j3" and in a separate console I am watching the
> > > build with 'top'. The build consumes 98% of both CPUs. If I stop the
> > > output in the build console with "Ctrl-S", one core goes to idle,
> > > while the other is in 50% waiting, then goes to 75% waiting. When I
> > > resume the build with "Ctrl-Q", the build starts to use both CPUs at
> > > 98-99%. The NFS4 use was minimal, as I did not login with Gnome, but
> > > just logged on the console. Also, the CPU that is in 75% waiting
> > > state changes occasionally. 'Top' shows pdflush in D state, using
> > > 5-6% of CPU.
> >
> > I forgot the traces:
> >
> > http://iucha.net/2.6.24-rc1/fw.1.gz
> > http://iucha.net/2.6.24-rc1/fw.2.gz
> > http://iucha.net/2.6.24-rc1/fw.3.gz
>
> Sorry for the delay - I've been fixing our server today.
>
> [ 263.685691] mm/page-writeback.c 655 wb_kupdate: pdflush(248) 24235 global 4593 0 0 wc _M tw 1024 sk 0
> [ 263.789648] requeue_io 301: inode 4031199 size 562 at 08:07(sda7)
> [ 263.789656] requeue_io 301: inode 4031231 size 329 at 08:07(sda7)
> [ 263.789660] requeue_io 301: inode 4031255 size 177 at 08:07(sda7)
> [ 263.789664] requeue_io 301: inode 4031268 size 94 at 08:07(sda7)
> [ 263.789667] requeue_io 301: inode 4031329 size 88 at 08:07(sda7)
> [ 263.789671] requeue_io 301: inode 4031351 size 74 at 08:07(sda7)
> [ 263.789674] requeue_io 301: inode 4031408 size 175 at 08:07(sda7)
> [ 263.789678] requeue_io 301: inode 4031413 size 129 at 08:07(sda7)
> [ 263.789681] requeue_io 301: inode 4031415 size 391 at 08:07(sda7)
> [ 263.789690] mm/page-writeback.c 655 wb_kupdate: pdflush(248) 24235 global 4593 0 0 wc _M tw 1024 sk 0
> [ 263.890184] requeue_io 301: inode 4031199 size 562 at 08:07(sda7)
> [ 263.890191] requeue_io 301: inode 4031231 size 329 at 08:07(sda7)
> [ 263.890195] requeue_io 301: inode 4031255 size 177 at 08:07(sda7)
> [ 263.890198] requeue_io 301: inode 4031268 size 94 at 08:07(sda7)
> [ 263.890202] requeue_io 301: inode 4031329 size 88 at 08:07(sda7)
> [ 263.890205] requeue_io 301: inode 4031351 size 74 at 08:07(sda7)
> [ 263.890208] requeue_io 301: inode 4031408 size 175 at 08:07(sda7)
> [ 263.890212] requeue_io 301: inode 4031413 size 129 at 08:07(sda7)
> [ 263.890215] requeue_io 301: inode 4031415 size 391 at 08:07(sda7)
> [ 263.890223] mm/page-writeback.c 655 wb_kupdate: pdflush(248) 24235 global 4593 0 0 wc _M tw 1024 sk 0
>
> It's about sda7, not NFSv4.
>
> Is it a Reiserfs? We have a fresh fix for it: http://lkml.org/lkml/2007/10/23/93

Yes, it is a Reiserfs. Incidentally it is the partition that holds
the kernel sources and build directory. The message states that the
same bug exists in 2.6.23 but I do not see the same behavior in
2.6.23. Anyway, I will apply the patch and see what I get.

Thanks,
florin

--
Bruce Schneier expects the Spanish Inquisition.
http://geekz.co.uk/schneierfacts/fact/163
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2007-10-31 13:19    [W:0.081 / U:0.032 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site