![]() | ||||||||||
Messages in this thread |
On Fri, Sep 23, 2005 at 04:46:19PM -0500, Dave Kleikamp wrote: > On Fri, 2005-09-23 at 15:59 -0500, Dave Kleikamp wrote: > > On Fri, 2005-09-23 at 15:57 -0500, Dave Kleikamp wrote: > > > On Fri, 2005-09-23 at 17:31 +0200, Andrea Arcangeli wrote: > > > > Hello, > > > > > > > > Can you try this updated patch? I believe the blk_congestion_wait is > > > > just wrong there, since there may be just one page being flushed. That > > > > sounds like a longstanding bug except it normally wouldn't trigger > > > > because the dirty levels never goes down near zero during heavy writes. > > > > > > fsx is now stuck in a loop somewhere, using 100% cpu. > > > > I hit send a little early. It eventually responded to a ^C. I'll try > > to get some more info. > > I'd guess that it's spinning in balance_dirty_pages. > /proc/<pid>/future_dirty is 25650 for fsx. It appears that Ok the good news is that this isn't a bug in the basic algorithm, but just in the implementation of it. > nr_reclaimable is not going to zero for some reason. Exactly, the !nr_reclaimable check is what I thought would have prevented an infinite loop to trigger... Unfortunately I couldn't reproduce on my laptop, I was working from the laptop the whole last week (I even did a presentation with this patch applied ;), I'll try to reprouce with fsx now. Thanks for the help! - 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-09-26 08:17 [from the cache] ©2003-2008 | ||||||||||