Re: [PATCH 5/6] writeback: sync expired inodes first in background writeback

[Jan Kara <jack@suse.cz>]

On Sun 24-04-11 11:15:31, Wu Fengguang wrote:
> > One of the many requirements for writeback is that if userspace is
> > continually dirtying pages in a particular file, that shouldn't cause
> > the kupdate function to concentrate on that file's newly-dirtied pages,
> > neglecting pages from other files which were less-recently dirtied. 
> > (and dirty nodes, etc).
> 
> Sadly I do find the old pages that the flusher never get a chance to
> catch and write them out.
  What kind of load do you use?

> In the below case, if the task dirties pages fast enough at the end of
> file, writeback_index will never get a chance to wrap back. There may
> be various variations of this case.
> 
> file head
> [          ***                        ==>***************]==>
>            old pages          writeback_index            fresh dirties
> 
> Ironically the current kernel relies on pageout() to catch these
> old pages, which is not only inefficient, but also not reliable.
> If a full LRU walk takes an hour, the old pages may stay dirtied
> for an hour.
  Well, the kupdate behavior has always been just a best-effort thing. We
always tried to handle well common cases but didn't try to solve all of
them. Unless we want to track dirty-age of every page (which we don't
want because it's too expensive), there is really no way to make syncing
of old pages 100% working for all the cases unless we do data-integrity
type of writeback for the whole inode - but that could create new problems
with stalling other files for too long I suspect.

> We may have to do (conditional) tagged ->writepages to safeguard users
> from losing data he'd expect to be written hours ago.
  Well, if the file is continuously written (and in your case it must be
even continuosly grown) I'd be content if we handle well the common case of
linear append (that happens for log files etc.). If we can do well for more
cases, even better but I'd be cautious not to disrupt some other more
common cases.

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>