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@xxxxxxxx> SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
