pdflush in D state

pdflush in D state

[Patrick Mau]

Hi there,

I have a strange observation regarding the pdflush kernel threads.
My system has 512MB RAM. The behavior is independand of the filesystem
type in use. I have tested ext2, ext3 and reiserfs.

The scenario goes like this:

- Create a new filesystem on a spare partition.
  All other partitions on this disk are NTFS and
  not mounted.
  
- Copy the whole XFree source there.

- "sync ; sync ; sync" and wait a few minutes
  (I really tried waiting more than 5 minutes)
  
- now there are 400MB used by the page cache

- start the build with "make World"

XFree creates its Makefiles using "imake".
After that it tries to remove many non-existant files to clean
the source tree.

This goes extremly fast, but after a few seconds pdflush
gets stuck in D state and tries to write back dirty pages.
The machine is completly unresponsive and "top" reports
75 percent IO wait time. The actual build has not even started.

I have no idea what pdflush is trying to do ...
The files are already written and there is no other disk
activity involved. I even tried single-user mode.

The kernel is BK current 2.5.59, the machine is a P4@2.4 GHz.

Has somebody else observed this ?

cheers,
Patrick

Re: pdflush in D state

[Andrew Morton]

Patrick Mau <mau@oscar.ping.de> wrote:
>
> This goes extremly fast, but after a few seconds pdflush
> gets stuck in D state and tries to write back dirty pages.
> The machine is completly unresponsive and "top" reports
> 75 percent IO wait time. The actual build has not even started.
> 

At a guess, I'd say that a disk device driver has dropped an interrupt and
I/O completion has not happened.

Check your kernel log and dmesg output for anything untoward, and then try
invoking sysrq-P and sysrq-T to find out where everythihg is stuck.

Re: pdflush in D state

[Dave Jones]

On Wed, Feb 05, 2003 at 11:41:39PM -0800, Andrew Morton wrote:

 > At a guess, I'd say that a disk device driver has dropped an interrupt and
 > I/O completion has not happened.
 > 
 > Check your kernel log and dmesg output for anything untoward, and then try
 > invoking sysrq-P and sysrq-T to find out where everythihg is stuck.

Unrelated to this problem, but it reminded me...
I've not heard any compelling arguments saying that these[1] patches
are wrong.

		Dave

[1] http://www.uwsg.iu.edu/hypermail/linux/kernel/0301.1/2217.html

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: pdflush in D state

[Robert Love]

On Thu, 2003-02-06 at 07:37, Dave Jones wrote:

> Unrelated to this problem, but it reminded me...
> I've not heard any compelling arguments saying that these[1] patches
> are wrong.

Ew, yes, real problem.

I will put it in my scheduler tree.

	Robert Love