Re: deadlock balance_dirty_pages() to be expected?

[Wu Fengguang <fengguang.wu@intel.com>]

On Tue, Oct 11, 2011 at 10:55:37PM +0800, Bernd Schubert wrote:
> >>>
> >>>> So the process is in D state ever since I wrote the first mail, just for
> >>>> 100MB writes. Even if it still would do something, it would be extremely
> >>>> slow. Sysrq-w then shows:
> >>>
> >>> So it's normal to catch such trace for 99% times.  But do you mean the
> >>> writeout bandwidth is lower than expected?
> >>
> >> If it really is still doing something, it is *ways* slower. Once I added
> >> bdi support, it finishes to write the 100MB file in my kvm test instance
> >> within a few seconds. Right now it is running for hours already... As I
> >> added a dump_stack() to our writepages() method, I also see that this
> >> function is never called.
> >
> > In your case it should be the default/forker thread that's doing the
> > (suboptimal) writeout:
> >
> > USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
> > root        17  0.0  0.0      0     0 ?        S    21:12   0:00 [bdi-default]
> 
> Ah thanks. Good to know, I will starting why this isn't doing anything.

The forker thread is simply not designed to do efficient and well
behaviored flushing.  So I'd suggest to leave it as is and focus on
ensuring the flush-XXX thread is started for your bdi.

> > In normal cases there are the flush-* threads doing the writeout:
> >
> > root      1146  0.0  0.0      0     0 ?        S    21:12   0:00 [flush-8:0]
> >
> >>>
> 
> [...]
> 
> >>> It's long time ago when the per-bdi writeback is introduced, I suspect.
> >>
> >> Ok, I can start to test if 2.6.32 also already deadlocks.
> >
> > I found the commit, it's introduced right in .32, hehe.
> >
> > commit 03ba3782e8dcc5b0e1efe440d33084f066e38cae
> > Author: Jens Axboe<jens.axboe@oracle.com>
> > Date:   Wed Sep 9 09:08:54 2009 +0200
> >
> >      writeback: switch to per-bdi threads for flushing data
> >
> >      This gets rid of pdflush for bdi writeout and kupdated style cleaning.
> 
> Yeah, that is why I wrote 2.6.32. But I just tested it - with 2.6.32 it 
> also works without additional bdi code. Sometime later this week I will 
> try to figure out the exact kernel and then commit causing the issue 
> (2.6.35 had several bdi additions I think).

OK, thanks for the feedback!

Thanks,
Fengguang