lkml.org 
[lkml]   [2004]   [Apr]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: pdflush eating a lot of CPU on heavy NFS I/O
Brent Cook <busterbcook@yahoo.com> wrote:
>
> On Wed, 28 Apr 2004, Andrew Morton wrote:
>
> > Brent Cook <busterbcook@yahoo.com> wrote:
> > >
> > > 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
> >
> > uh-huh.
> >
> > Does this fix it?
>
> I'm going to run a compile/load test overnight, but the test that
> triggered it every time previously failed to do so with this patch.

OK, thanks. A better patch would be:


diff -puN fs/fs-writeback.c~writeback-livelock-fix-2 fs/fs-writeback.c
--- 25/fs/fs-writeback.c~writeback-livelock-fix-2 2004-04-28 21:19:32.779061976 -0700
+++ 25-akpm/fs/fs-writeback.c 2004-04-28 21:20:11.080239312 -0700
@@ -176,11 +176,12 @@ __sync_single_inode(struct inode *inode,
if (wbc->for_kupdate) {
/*
* For the kupdate function we leave the inode
- * where it is on sb_dirty so it will get more
+ * at the head of sb_dirty so it will get more
* writeout as soon as the queue becomes
* uncongested.
*/
inode->i_state |= I_DIRTY_PAGES;
+ list_move_tail(&inode->i_list, &sb->s_dirty);
} else {
/*
* Otherwise fully redirty the inode so that
_

> pdflush is behaving so far, and I'll say you've figured it out for now,
> with the final verdict in about 8 hours.
>
> Does this mean that, if there were too many dirty pages and not enough
> time to write them all back, that the dirty page list just stopped being
> traversed, stuck on a single page?

No.. There's all sorts of livelock avoidance code in there and I keep on
forgetting that sometimes writepage won't write the dang page at all -
instead it just redirties the page (and hence the inode).

Now, that redirtying of the inode _should_ have moved the inode off the
s_io list and onto the s_dirty list. But for some reason it looks like it
didn't, so we get stuck in a loop. I need to think about it a bit more.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:02    [W:1.213 / U:0.004 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site