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 [email protected] GHz.
Has somebody else observed this ?
cheers,
Patrick
Patrick Mau <[email protected]> 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.
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
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