Re: pdflush eating a lot of CPU on heavy NFS I/O

[Brent Cook]

On Wed, 28 Apr 2004, Andrew Morton wrote:

> Brent Cook <busterbcook@xxxxxxxxx> wrote:
> >
> >   PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME CPU COMMAND
> >      7 root      25   0     0    0     0 RW   99.4  0.0 415:26   0 pdflush
>
> This getting very irritating.  Cannot reproduce it with a 2.4 server, gcc
> 3.4.0, 2.6.6-rc3 client.  grrr.
>
> Could you please apply the below two patches, then wait for pdflush to go
> nuts, then do:
>
> 	echo 1 > /proc/sys/debug/0
> 	echo 0 > /proc/sys/debug/0
> 	dmesg -s 1000000 > foo
>
> then mail me foo?  It probably won't tell me much, but one has to start
> somewhere.
>

That seems like a good start. I compiled arts from KDE from an NFS
directory, and about 4 minutes into it, pdflush appears to be hung-up
writing a single inode. dmesg just contains this over and over:

...
sync_sb_inodes: write inode c55d25bc
__sync_single_inode: writepages in nr_pages:25 nr_to_write:949
pages_skipped:0 en:0
__sync_single_inode: writepages in nr_pages:25 nr_to_write:949
pages_skipped:0 en:0
sync_sb_inodes: write inode c55d25bc
__sync_single_inode: writepages in nr_pages:25 nr_to_write:949
pages_skipped:0 en:0
__sync_single_inode: writepages in nr_pages:25 nr_to_write:949
pages_skipped:0 en:0
sync_sb_inodes: write inode c55d25bc
....

After rebooting, I tried repeating the experiment compiling from /tmp and
pdflush behaved. It didn't matter whether the NFS share was mounted at the
time, just whether the source was compiled from the share or elsewhere.

FYI, my fstab on this test machine (the PIII with 256MB/i815 chipset) is
pretty boring:

/dev/hda1        swap             swap        defaults         0   0
/dev/hda2        /                reiserfs    defaults         1   1
ozma:/home       /home            nfs         rw               0   0
/dev/cdrom       /mnt/cdrom       iso9660     noauto,owner,ro  0   0
/dev/fd0         /mnt/floppy      auto        noauto,owner     0   0
devpts           /dev/pts         devpts      gid=5,mode=620   0   0
proc             /proc            proc        defaults         0   0
none             /sys             sysfs       defaults         0   0

The share is exported from the 2.4.25 server as follows:

/home snowball2(rw,async,no_root_squash)

 - Brent
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/