From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-f196.google.com ([209.85.220.196]:34272 "EHLO mail-qk0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S937343AbdD0TnQ (ORCPT ); Thu, 27 Apr 2017 15:43:16 -0400 Received: by mail-qk0-f196.google.com with SMTP id u75so6191330qka.1 for ; Thu, 27 Apr 2017 12:43:16 -0700 (PDT) Date: Thu, 27 Apr 2017 15:43:14 -0400 From: Josef Bacik To: viro@ZenIV.linux.org.uk Cc: jack@suse.cz, david@fromorbit.com, linux-fsdevel@vger.kernel.org, kernel-team@fb.com Subject: Re: [PATCH] fs: don't set *REFERENCED on single use objects Message-ID: <20170427194313.GA6299@destiny> References: <1492545857-3695-1-git-send-email-jbacik@fb.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1492545857-3695-1-git-send-email-jbacik@fb.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Tue, Apr 18, 2017 at 04:04:17PM -0400, Josef Bacik wrote: > By default we set DCACHE_REFERENCED and I_REFERENCED on any dentry or > inode we create. This is problematic as this means that it takes two > trips through the LRU for any of these objects to be reclaimed, > regardless of their actual lifetime. With enough pressure from these > caches we can easily evict our working set from page cache with single > use objects. So instead only set *REFERENCED if we've already been > added to the LRU list. This means that we've been touched since the > first time we were accessed, and so more likely to need to hang out in > cache. > > To illustrate this issue I wrote the following scripts > > https://github.com/josefbacik/debug-scripts/tree/master/cache-pressure > > on my test box. It is a single socket 4 core CPU with 16gib of RAM and > I tested on an Intel 2tib NVME drive. The cache-pressure.sh script > creates a new file system and creates 2 6.5gib files in order to take up > 13gib of the 16gib of ram with pagecache. Then it runs a test program > that reads these 2 files in a loop, and keeps track of how often it has > to read bytes for each loop. On an ideal system with no pressure we > should have to read 0 bytes indefinitely. The second thing this script > does is start a fs_mark job that creates a ton of 0 length files, > putting pressure on the system with slab only allocations. On exit the > script prints out how many bytes were read by the read-file program. > The results are as follows > > Without patch: > /mnt/btrfs-test/reads/file1: total read during loops 27262988288 > /mnt/btrfs-test/reads/file2: total read during loops 27262976000 > > With patch: > /mnt/btrfs-test/reads/file2: total read during loops 18640457728 > /mnt/btrfs-test/reads/file1: total read during loops 9565376512 > > This patch results in a 50% reduction of the amount of pages evicted > from our working set. > > Signed-off-by: Josef Bacik Hello Al, Can we get this included in the upcoming merge window? Thanks, Josef