Re: [PATCH 1/2] writeback: Improve busyloop prevention

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

> > >   I did some calculations. Default journal size for a filesystem of your
> > > size is 128 MB which allows recording of around 128 GB of data. So your
> > > test probably didn't hit the point where the journal is recycled yet. An
> > > easy way to make sure journal gets recycled is to set its size to a lower
> > > value when creating the filesystem by
> > >   mke2fs -J size=8
> > 
> > I tried the "-J size=8" and get similar interesting results for
> > ext3/4, before/after this change:
> > 
> >                 if (work->for_kupdate) {
> >                         oldest_jif = jiffies -
> >                                 msecs_to_jiffies(dirty_expire_interval * 10);
> > -                       work->older_than_this = &oldest_jif;
> > -               }
> > +               } else if (work->for_background)
> > +                       oldest_jif = jiffies;
> > 
> > So I only attach the graphs for one case:
> > 
> > ext4-1dd-4k-8p-2941M-1000M:10-3.1.0-ioless-full-next-20111025+
> > 
> > Two of the graphs are very interesting. balance_dirty_pages-pause.png
> > shows increasingly large negative pause times, which indicates large
> > delays inside some ext4's routines.
>   Likely we are hanging waiting for transaction start. 8 MB journal puts
> rather big pressure on journal space so we end up waiting on kjournald a
> lot. But I'm not sure why wait times would increase on large scale - with
> ext4 it's harder to estimate used journal space because it uses extents so
> the amount of metadata written depends on fragmentation. If you could post
> ext3 graphs, maybe I could make some sense from it... 

Oops it's me that messed it up again -- two chunks were lost during
when rebasing the patchset which leads to the misbehavior -- big sorry!