Messages in this thread | | | Date | Tue, 7 Mar 2006 04:08:21 -0800 | From | Andrew Morton <> | Subject | Re: pdflush and high load |
| |
Andres Salomon <dilinger@debian.org> wrote: > > Hi, > > (2nd attempt at posting this; the first one appears to have > disappeared?)
It came through.
> Basically, what ends up happening on my system is, each pdflush process > is handling background_writeout(), encountering congestion, and calling > blk_congestion_wait(WRITE, HZ/10) after every loop.
Yes, the do-we-need-another-thread algorithm is rather too naive. I could swear it _used_ to work OK. Maybe something changed to cause individual threads to block for longer than they used to. That would be an independent problem - one pdflush instance is supposed to be able to handle many queues (I tested one instance on 12 disks and it worked OK. But that was 4-5 years ago)
> My solution to the problem is to keep the blk_congestion_wait() sleep as > uninterruptible, but add a check to the background_writeout() loop to > check whether the current pdflush thread is actually doing anything > useful; if it's not, just give up.
It would be better to not start a new thread in the first place.
- 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/
| |