Re: [PATCH] xfs: Timely free truncated dirty pages

[Jan Kara <jack@suse.cz>]

Hi,

On Wed 11-01-17 09:07:51, Vlastimil Babka wrote:
> On 01/10/2017 11:17 AM, Jan Kara wrote:
> > Commit 99579ccec4e2 "xfs: skip dirty pages in ->releasepage()" started
> > to skip dirty pages in xfs_vm_releasepage() which also has the effect
> > that if a dirty page is truncated, it does not get freed by
> > block_invalidatepage() and is lingering in LRU list waiting for reclaim.
> > So a simple loop like:
> > 
> > while true; do
> > 	dd if=/dev/zero of=file bs=1M count=100
> > 	rm file
> > done
> > 
> > will keep using more and more memory until we hit low watermarks and
> > start pagecache reclaim which will eventually reclaim also the truncate
> > pages. Keeping these truncated (and thus never usable) pages in memory
> > is just a waste of memory, is unnecessarily stressing page cache
> > reclaim, and is also confusing users thinking they are running out of
> > memory.
> 
> So the impact is even worse than that, as it's the kernel that is
> actually confused, while the user still gets the impression of memory
> being available.
> According to the reporter, this bug has manifested as anonymous mmap()
> returning with ENOMEM in their workload (some benchmark), which does not
> happen anymore after switching from xfs to ext4.

OK, I've changed the changelog to contain:

... and reportedly also leads to anonymous mmap(2) returning ENOMEM
prematurely.

<snip>

> So this would explain the ENOMEM, and how this bug is a problem for
> workloads that truncate/remove files on xfs, and at the same time rely
> on anonymous mmap(). In that case, these mmaps can apparently start
> failing if there's no other source of sufficient memory pressure to let
> reclaim get rid of the truncated pages on LRU. This should be serious
> enough for a stable backport IMHO.

OK, added CC to stable.
	
								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR