fs: add fincore(2) (mincore(2) for file descriptors)

For a microbenchmark that sequentially queries whether the pages of a large file are in memory fincore is 7-11x faster than mmap+mincore+munmap when querying one page a time (Pentium 4 running a 32 bit SMP kernel).

In this patch find_get_page() is called for each page, which in turn calls rcu_read_lock(), for each page. We have found that amortizing

Add the fincore() system call. fincore() is mincore() for file descriptors.

The functionality of fincore() can be emulated with an mmap(), mincore(), and munmap(), but this emulation requires more system calls and requires page table modifications. fincore() can provide a significant performance improvement for non-sequential in-core queries.

Add the fincore() system call. fincore() is mincore() for file descriptors.

The functionality of fincore() can be emulated with an mmap(), mincore(), and munmap(), but this emulation requires more system calls and requires page table modifications. fincore() can provide a significant performance improvement for non-sequential in-core queries.

Signed-off-by Chris Frost <[email protected]>

Signed-off-by Steve VanDeBogart <[email protected]>

---

Notes on micro and macro performance and on a potential optimization:

For a microbenchmark that sequentially queries whether the pages of a large file are in memory fincore is 7-11x faster than mmap+mincore+munmap when querying one page a time (Pentium 4 running a 32 bit SMP kernel). When querying 1024 pages at a time the two approaches perform comparably. However, an application cannot always amortize calls; e.g., non-sequential reads. These improvements are increased significantly by amortizing the RCU work done by each find_get_page() call, but this optimization does not affect our macrobenchmarks (more in third paragraph).

We introduced this system call while modifying SQLite and the GIMP to request large prefetches for what would otherwise be non-sequential reads. As a macrobenchmark, we see a 125s SQLite query (72s system time) reduced to 75s (18s system time) by using fincore() instead of mincore(). This speedup of course varies by benchmark and benchmarks size; we've seen both minimal speedups and 1000x speedups. More on these benchmarks in the publication _Reducing Seek Overhead with Application-Directed Prefetching_ in USENIX ATC 2009 and at http://libprefetch.cs.ucla.edu/.

In this patch find_get_page() is called for each page, which in turn calls rcu_read_lock(), for each page. We have found that amortizing these RCU calls, e.g., by introducing a variant of find_get_pages_contig() that does not skip missing pages, can speedup the above microbenchmark by 260x when querying many pages per system call. But we have not observed noticeable improvements to our macrobenchmarks. I'd be happy to also post this change or look further into it, but this seems like a reasonable first patch, at least.

 include/linux/syscalls.h           |    2 
 fs/fincore.c                       |  135 +++++++++++++++++++++++++++
 fs/Makefile                        |    2 
 arch/x86/ia32/ia32entry.S          |    1 
 arch/x86/include/asm/unistd_32.h   |    3 
 arch/x86/include/asm/unistd_64.h   |    2 
 arch/x86/kernel/syscall_table_32.S |    1 
 include/asm-generic/unistd.h       |    5 -
 8 files changed, 148 insertions(+), 3 deletions(-)

include/linux/syscalls.h +2 -0

index a990ace..1e8f00f 100644
@@ -534,6 +534,8 @@ asmlinkage long sys_munlockall(void);
 asmlinkage long sys_madvise(unsigned long start, size_t len, int behavior);
 asmlinkage long sys_mincore(unsigned long start, size_t len,
 				unsigned char __user * vec);
+asmlinkage long sys_fincore(unsigned int fd, loff_t start, loff_t len,
+				unsigned char __user *vec);
 
 asmlinkage long sys_pivot_root(const char __user *new_root,
 				const char __user *put_old);

fs/fincore.c new file +135 -0

new file mode 100644
index 0000000..6b74cc4
@@ -0,0 +1,135 @@
+/*
+ *	fs/fincore.c
+ *
+ * Copyright (C) 2009, 2010 Chris Frost, UC Regents
+ * Copyright (C) 2008 Steve VanDeBogart, UC Regents
+ */
+
+/*
+ * The fincore() system call.
+ */
+#include <linux/fs.h>
+#include <linux/file.h>
+#include <linux/pagemap.h>
+#include <linux/syscalls.h>
+#include <linux/uaccess.h>
+
+static unsigned char fincore_page(struct address_space *mapping, pgoff_t pgoff)
+{
+	unsigned char present = 0;
+	struct page *page = find_get_page(mapping, pgoff);
+	if (page) {
+		present = PageUptodate(page);
+		page_cache_release(page);
+	}
+
+	return present;
+}
+
+/*
+ * The fincore(2) system call.
+ *
+ * fincore() returns the memory residency status of the pages backing
+ * a file range specified by fd and [start, start + len).
+ * The status is returned in a vector of bytes.  The least significant
+ * bit of each byte is 1 if the referenced page is in memory, otherwise
+ * it is zero.
+ *
+ * Because the status of a page can change after fincore() checks it
+ * but before it returns to the application, the returned vector may
+ * contain stale information.  Only locked pages are guaranteed to
+ * remain in memory.
+ *
+ * return values:
+ *  zero    - success
+ *  -EBADF  - fd is an illegal file descriptor
+ *  -EFAULT - vec points to an illegal address
+ *  -EINVAL - start is not a multiple of PAGE_CACHE_SIZE or start + len
+ *		is larger than the size of the file
+ *  -EAGAIN - A kernel resource was temporarily unavailable.
+ */
+SYSCALL_DEFINE4(fincore, unsigned int, fd, loff_t, start, loff_t, len,
+		unsigned char __user *, vec)
+{
+	long retval;
+	loff_t pgoff = start >> PAGE_SHIFT;
+	loff_t pgend;
+	loff_t npages;
+	struct file *filp;
+	int fput_needed;
+	loff_t file_nbytes;
+	loff_t file_npages;
+	unsigned char *tmp = NULL;
+	unsigned char tmp_small[64];
+	unsigned tmp_count;
+	int i;
+
+	/* Check the start address: needs to be page-aligned.. */
+	if (start & ~PAGE_CACHE_MASK)
+		return -EINVAL;
+
+	npages = len >> PAGE_SHIFT;
+	npages += (len & ~PAGE_MASK) != 0;
+
+	pgend = pgoff + npages;
+
+	filp = fget_light(fd, &fput_needed);
+	if (!filp)
+		return -EBADF;
+
+	if (filp->f_dentry->d_inode->i_mode & S_IFBLK)
+		file_nbytes = filp->f_dentry->d_inode->i_bdev->bd_inode->i_size << 9;
+	else
+		file_nbytes = filp->f_dentry->d_inode->i_size;
+
+	file_npages = file_nbytes >> PAGE_SHIFT;
+	file_npages += (file_nbytes & ~PAGE_MASK) != 0;
+
+	if (pgoff >= file_npages || pgend > file_npages) {
+		retval = -EINVAL;
+		goto done;
+	}
+
+	if (!access_ok(VERIFY_WRITE, vec, npages)) {
+		retval = -EFAULT;
+		goto done;
+	}
+
+	/*
+	 * Allocate buffer vector page.
+	 * Optimize allocation for small values of npages because the
+	 * __get_free_page() call doubles fincore(2) runtime when npages == 1.
+	 */
+	if (npages <= sizeof(tmp_small)) {
+		tmp = tmp_small;
+		tmp_count = sizeof(tmp_small);
+	} else {
+		tmp = (void *) __get_free_page(GFP_USER);
+		if (!tmp) {
+			retval = -EAGAIN;
+			goto done;
+		}
+		tmp_count = PAGE_SIZE;
+	}
+
+	while (pgoff < pgend) {
+		/*
+		 * Do at most tmp_count entries per iteration, due to
+		 * the temporary buffer size.
+		 */
+		for (i = 0; pgoff < pgend && i < tmp_count; pgoff++, i++)
+			tmp[i] = fincore_page(filp->f_mapping, pgoff);
+
+		if (copy_to_user(vec, tmp, i)) {
+			retval = -EFAULT;
+			break;
+		}
+		vec += i;
+	}
+	retval = 0;
+done:
+	if (tmp && tmp != tmp_small)
+		free_page((unsigned long) tmp);
+	fput_light(filp, fput_needed);
+	return retval;
+}

fs/Makefile +1 -1

index af6d047..a3ccd6b 100644
@@ -11,7 +11,7 @@ obj-y :=	open.o read_write.o file_table.o super.o \
 		attr.o bad_inode.o file.o filesystems.o namespace.o \
 		seq_file.o xattr.o libfs.o fs-writeback.o \
 		pnode.o drop_caches.o splice.o sync.o utimes.o \
-		stack.o fs_struct.o
+		stack.o fs_struct.o fincore.o
 
 ifeq ($(CONFIG_BLOCK),y)
 obj-y +=	buffer.o bio.o block_dev.o direct-io.o mpage.o ioprio.o

include/asm-generic/unistd.h +4 -1

index d76b66a..ce76dc8 100644
@@ -623,8 +623,11 @@ __SYSCALL(__NR_rt_tgsigqueueinfo, sys_rt_tgsigqueueinfo)
 #define __NR_perf_event_open 241
 __SYSCALL(__NR_perf_event_open, sys_perf_event_open)
 
+#define __NR_fincore 242
+__SYSCALL(__NR_fincore, sys_fincore)
+
 #undef __NR_syscalls
-#define __NR_syscalls 242
+#define __NR_syscalls 243
 
 /*
  * All syscalls below here should go away really,

arch/x86/ia32/ia32entry.S +1 -0

index 581b056..cbf96e6 100644
@@ -841,4 +841,5 @@ ia32_sys_call_table:
 	.quad compat_sys_pwritev
 	.quad compat_sys_rt_tgsigqueueinfo	/* 335 */
 	.quad sys_perf_event_open
+	.quad sys_fincore
 ia32_syscall_end:

arch/x86/include/asm/unistd_32.h +2 -1

index 6fb3c20..088b235 100644
@@ -342,10 +342,11 @@
 #define __NR_pwritev		334
 #define __NR_rt_tgsigqueueinfo	335
 #define __NR_perf_event_open	336
+#define __NR_fincore		337
 
 #ifdef __KERNEL__
 
-#define NR_syscalls 337
+#define NR_syscalls 338
 
 #define __ARCH_WANT_IPC_PARSE_VERSION
 #define __ARCH_WANT_OLD_READDIR

arch/x86/include/asm/unistd_64.h +2 -0

index 8d3ad0a..ebc04b5 100644
@@ -661,6 +661,8 @@ __SYSCALL(__NR_pwritev, sys_pwritev)
 __SYSCALL(__NR_rt_tgsigqueueinfo, sys_rt_tgsigqueueinfo)
 #define __NR_perf_event_open			298
 __SYSCALL(__NR_perf_event_open, sys_perf_event_open)
+#define __NR_fincore				299
+__SYSCALL(__NR_fincore, sys_fincore)
 
 #ifndef __NO_STUBS
 #define __ARCH_WANT_OLD_READDIR

arch/x86/kernel/syscall_table_32.S +1 -0

index 0157cd2..1fdc8bc 100644
@@ -336,3 +336,4 @@ ENTRY(sys_call_table)
 	.long sys_pwritev
 	.long sys_rt_tgsigqueueinfo	/* 335 */
 	.long sys_perf_event_open
+	.long sys_fincore

Signature · 10 lines

1.5.4.3

-- 
Chris Frost
http://www.frostnet.net/chris/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Add the fincore() system call. fincore() is mincore() for file descriptors.

The functionality of fincore() can be emulated with an mmap(), mincore(), and munmap(), but this emulation requires more system calls and requires page table modifications. fincore() can provide a significant performance improvement for non-sequential in-core queries.

Signed-off-by Chris Frost <[email protected]>

Signed-off-by Steve VanDeBogart <[email protected]>

---

Notes on micro and macro performance and on a potential optimization:

For a microbenchmark that sequentially queries whether the pages of a large file are in memory fincore is 7-11x faster than mmap+mincore+munmap when querying one page a time (Pentium 4 running a 32 bit SMP kernel). When querying 1024 pages at a time the two approaches perform comparably. However, an application cannot always amortize calls; e.g., non-sequential reads. These improvements are increased significantly by amortizing the RCU work done by each find_get_page() call, but this optimization does not affect our macrobenchmarks (more in third paragraph).

We introduced this system call while modifying SQLite and the GIMP to request large prefetches for what would otherwise be non-sequential reads. As a macrobenchmark, we see a 125s SQLite query (72s system time) reduced to 75s (18s system time) by using fincore() instead of mincore(). This speedup of course varies by benchmark and benchmarks size; we've seen both minimal speedups and 1000x speedups. More on these benchmarks in the publication _Reducing Seek Overhead with Application-Directed Prefetching_ in USENIX ATC 2009 and at http://libprefetch.cs.ucla.edu/.

In this patch find_get_page() is called for each page, which in turn calls rcu_read_lock(), for each page. We have found that amortizing these RCU calls, e.g., by introducing a variant of find_get_pages_contig() that does not skip missing pages, can speedup the above microbenchmark by 260x when querying many pages per system call. But we have not observed noticeable improvements to our macrobenchmarks. I'd be happy to also post this change or look further into it, but this seems like a reasonable first patch, at least.

...

new file mode 100644
index 0000000..6b74cc4

fs/fincore.c new file +17 -0

@@ -0,0 +1,135 @@
+/*
+ *	fs/fincore.c
+ *
+ * Copyright (C) 2009, 2010 Chris Frost, UC Regents
+ * Copyright (C) 2008 Steve VanDeBogart, UC Regents
+ */
+
+/*
+ * The fincore() system call.
+ */
+#include <linux/fs.h>
+#include <linux/file.h>
+#include <linux/pagemap.h>
+#include <linux/syscalls.h>
+#include <linux/uaccess.h>
+
+static unsigned char fincore_page(struct address_space *mapping, pgoff_t pgoff)

fs/fincore.c new file +27 -0

+/*
+ * The fincore(2) system call.
+ *
+ * fincore() returns the memory residency status of the pages backing
+ * a file range specified by fd and [start, start + len).
+ * The status is returned in a vector of bytes.  The least significant
+ * bit of each byte is 1 if the referenced page is in memory, otherwise
+ * it is zero.
+ *
+ * Because the status of a page can change after fincore() checks it
+ * but before it returns to the application, the returned vector may
+ * contain stale information.  Only locked pages are guaranteed to
+ * remain in memory.
+ *
+ * return values:
+ *  zero    - success
+ *  -EBADF  - fd is an illegal file descriptor
+ *  -EFAULT - vec points to an illegal address
+ *  -EINVAL - start is not a multiple of PAGE_CACHE_SIZE or start + len
+ *		is larger than the size of the file
+ *  -EAGAIN - A kernel resource was temporarily unavailable.
+ */
+SYSCALL_DEFINE4(fincore, unsigned int, fd, loff_t, start, loff_t, len,
+		unsigned char __user *, vec)
+{
+	long retval;
+	loff_t pgoff = start >> PAGE_SHIFT;

fs/fincore.c new file +7 -0

+	/* Check the start address: needs to be page-aligned.. */
+	if (start & ~PAGE_CACHE_MASK)
+		return -EINVAL;
+
+	npages = len >> PAGE_SHIFT;
+	npages += (len & ~PAGE_MASK) != 0;
+

fs/fincore.c new file +28 -0

+	/*
+	 * Allocate buffer vector page.
+	 * Optimize allocation for small values of npages because the
+	 * __get_free_page() call doubles fincore(2) runtime when npages == 1.
+	 */
+	if (npages <= sizeof(tmp_small)) {
+		tmp = tmp_small;
+		tmp_count = sizeof(tmp_small);
+	} else {
+		tmp = (void *) __get_free_page(GFP_USER);
+		if (!tmp) {
+			retval = -EAGAIN;
+			goto done;
+		}
+		tmp_count = PAGE_SIZE;
+	}
+
+	while (pgoff < pgend) {
+		/*
+		 * Do at most tmp_count entries per iteration, due to
+		 * the temporary buffer size.
+		 */
+		for (i = 0; pgoff < pgend && i < tmp_count; pgoff++, i++)
+			tmp[i] = fincore_page(filp->f_mapping, pgoff);
+
+		if (copy_to_user(vec, tmp, i)) {
+			retval = -EFAULT;
+			break;

Quoted 8 lines · On Wed, 20 Jan 2010 13:57:12 -0800 Chris Frost <[email protected]> wrote:

In this patch find_get_page() is called for each page, which in turn calls rcu_read_lock(), for each page. We have found that amortizing these RCU calls, e.g., by introducing a variant of find_get_pages_contig() that does not skip missing pages, can speedup the above microbenchmark by 260x when querying many pages per system call. But we have not observed noticeable improvements to our macrobenchmarks. I'd be happy to also post this change or look further into it, but this seems like a reasonable first patch, at least.

I must say, the syscall appeals to my inner geek. Lot of applications are leaving a lot of time on the floor due to bad disk access patterns. A really smart library which uses this facility could help all over the place.

Is it likely that these changes to SQLite and Gimp would be merged into the upstream applications?

fs/fincore.c line 91

Quoted 4 lines

fs/fincore.c new file +4 -0

+	if (pgoff >= file_npages || pgend > file_npages) {
+		retval = -EINVAL;
+		goto done;
+	}

Should this return -EINVAL, or should it just return "0": nothing there?

Bear in mind that this code is racy against truncate (I think?), and this is "by design". If that race does occur, we want to return something graceful to userspace and I suggest that "nope, nothing there" is a more graceful result that "erk, you screwed up". Because the application _didn't_ screw up: the pages were there when the syscall was first performed.

Quoted 2 lines

Is it likely that these changes to SQLite and Gimp would be merged into the upstream applications?

Changes to the GIMP fit nicely into the code structure, so it's feasible to push this kind of optimization upstream. The changes in SQLite are a bit more focused on the benchmark, but a more general approach is not conceptually difficult. SQLite may not want the added complexity, but other database may be interested in the performance improvement.

Of course, these kernel changes are needed before any application can optimize its IO as we did with libprefetch.

Quoted 11 lines · On Wed, 27 Jan 2010 23:42:35 -0800 (PST) Steve VanDeBogart…

Quoted 2 lines

Is it likely that these changes to SQLite and Gimp would be merged into the upstream applications?

Changes to the GIMP fit nicely into the code structure, so it's feasible to push this kind of optimization upstream. The changes in SQLite are a bit more focused on the benchmark, but a more general approach is not conceptually difficult. SQLite may not want the added complexity, but other database may be interested in the performance improvement.

Of course, these kernel changes are needed before any application can optimize its IO as we did with libprefetch.

That didn't really answer my question.

If there's someone signed up and motivated to do the hard work of getting these changes integrated into the upstream applications then that makes us more interested. If, however it was some weekend proof-of-concept hack which shortly dies an instadeath then... meh, not so much.

On Wed, 27 Jan 2010 23:42:35 -0800 (PST) Steve VanDeBogart <vandebo-

Quoted 9 lines

Quoted 2 lines

Is it likely that these changes to SQLite and Gimp would be merged into the upstream applications?

Changes to the GIMP fit nicely into the code structure, so it's feasible to push this kind of optimization upstream. The changes in SQLite are a bit more focused on the benchmark, but a more general approach is not conceptually difficult. SQLite may not want the added complexity, but other database may be interested in the performance improvement.

Quoted 2 lines

Of course, these kernel changes are needed before any application can optimize its IO as we did with libprefetch.

That didn't really answer my question.
If there's someone signed up and motivated to do the hard work of getting these changes integrated into the upstream applications then that makes us more interested. If, however it was some weekend proof-of-concept hack which shortly dies an instadeath then... meh, not so much.

Add the fincore() system call. fincore() is mincore() for file descriptors.

The functionality of fincore() can be emulated with an mmap(), mincore(), and munmap(), but this emulation requires more system calls and requires page table modifications. fincore() can provide a significant performance improvement for non-sequential in-core queries.

Quoted 6 lines · Chris Frost

Add the fincore() system call. fincore() is mincore() for file descriptors.

The functionality of fincore() can be emulated with an mmap(), mincore(), and munmap(), but this emulation requires more system calls and requires page table modifications. fincore() can provide a significant performance improvement for non-sequential in-core queries.

In addition to being expensive, mmap/mincore/munmap perturb the VM's eviction algorithm -- a page is less likely to be evicted if it's mmapped when being considered for eviction.

I frequently see this happen when using mincore(1) from
http://bitbucket.org/radii/mincore/ -- "watch mincore -v *.big" while *.big are being sequentially read results in a significant number of pages remaining in-core, whereas if I only run mincore after the sequential read is complete, the large files will be nearly-completely out of core (except for the tail of the last file, of course).

It's very interesting to watch
% watch --interval=.5 mincore -v *

while an IO-intensive process is happening, such as mke2fs on a filesystem image.

So, I support the addition of fincore(2) and would use it if it were merged.

Andy and Chris,

Quoted 19 lines · Andy Isaacson

Quoted 6 lines · Chris Frost

Add the fincore() system call. fincore() is mincore() for file descriptors.

The functionality of fincore() can be emulated with an mmap(), mincore(), and munmap(), but this emulation requires more system calls and requires page table modifications. fincore() can provide a significant performance improvement for non-sequential in-core queries.

In addition to being expensive, mmap/mincore/munmap perturb the VM's eviction algorithm -- a page is less likely to be evicted if it's mmapped when being considered for eviction.

I frequently see this happen when using mincore(1) from
http://bitbucket.org/radii/mincore/ -- "watch mincore -v *.big" while *.big are being sequentially read results in a significant number of pages remaining in-core, whereas if I only run mincore after the sequential read is complete, the large files will be nearly-completely out of core (except for the tail of the last file, of course).

Quoted 8 lines

It's very interesting to watch
% watch --interval=.5 mincore -v *

while an IO-intensive process is happening, such as mke2fs on a filesystem image.

So, I support the addition of fincore(2) and would use it if it were merged.

I'd like to advocate the "pagecache object collections", a ftrace based alternative:

        http://lkml.org/lkml/2010/2/9/156

Which will provide much more information than fincore(). I'd really appreciate it if you can join and use the general "pagecache object collections" facility.

Quoted 6 lines

Add the fincore() system call. fincore() is mincore() for file descriptors.

The functionality of fincore() can be emulated with an mmap(), mincore(), and munmap(), but this emulation requires more system calls and requires page table modifications. fincore() can provide a significant performance improvement for non-sequential in-core queries.

In addition to being expensive, mmap/mincore/munmap perturb the VM's eviction algorithm -- a page is less likely to be evicted if it's mmapped when being considered for eviction.

I frequently see this happen when using mincore(1) from
http://bitbucket.org/radii/mincore/ -- "watch mincore -v *.big" while *.big are being sequentially read results in a significant number of pages remaining in-core, whereas if I only run mincore after the sequential read is complete, the large files will be nearly-completely out of core (except for the tail of the last file, of course).

It's very interesting to watch
% watch --interval=.5 mincore -v *

while an IO-intensive process is happening, such as mke2fs on a filesystem image.

So, I support the addition of fincore(2) and would use it if it were merged.

-andy
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

We introduced this system call while modifying SQLite and the GIMP to request large prefetches for what would otherwise be non-sequential reads. As a macrobenchmark, we see a 125s SQLite query (72s system time) reduced to 75s (18s system time) by using fincore() instead of mincore(). This speedup of course varies by benchmark and benchmarks size; we've seen both minimal speedups and 1000x speedups. More on these benchmarks in the publication _Reducing Seek Overhead with Application-Directed Prefetching_ in USENIX ATC 2009 and at http://libprefetch.cs.ucla.edu/.

Quoted 8 lines · Chris Frost

We introduced this system call while modifying SQLite and the GIMP to request large prefetches for what would otherwise be non-sequential reads. As a macrobenchmark, we see a 125s SQLite query (72s system time) reduced to 75s (18s system time) by using fincore() instead of mincore(). This speedup of course varies by benchmark and benchmarks size; we've seen both minimal speedups and 1000x speedups. More on these benchmarks in the publication _Reducing Seek Overhead with Application-Directed Prefetching_ in USENIX ATC 2009 and at http://libprefetch.cs.ucla.edu/.

My first thought was:

Why is calling fincore() and then issuing reads better than simply calling readahead() on the same range? I.e. why is readahead() (or POSIX_FADV_WILLNEED) unsuitable to give the same result? Or even issuing lots of AIO requests.

I knew that I was missing something, so I read the paper ;-) I don't fully understand it, but *think* that it says fincore() is used to detect when the kernel is evicting pages faster than libprefetch had planned for, implying memory pressure, so it adjusts its planning in response.

Interesting idea, though I wonder if it wouldn't be even better to have a direct way to ask the kernel "tell me when there is memory pressure causing my file to be evicted".