The faultaround improves the file read performance, whereas pages which
can be dropped by drop_caches are reduced. On some systems, The amount of
freeable pages under memory pressure is more important than read
performance. So It prefers to be selectable.
This patch adds a new kernel cmdline parameter "nofaultaround"
for situations where users want to disable faultaround.
Signed-off-by: Chanho Min <[email protected]>
---
mm/memory.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/mm/memory.c b/mm/memory.c
index 4879b42..c36a96f 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2888,6 +2888,14 @@ static int __init fault_around_debugfs(void)
late_initcall(fault_around_debugfs);
#endif
+static bool enable_fault_around = true;
+static int __init disable_fault_around(char *s)
+{
+ enable_fault_around = false;
+ return 1;
+}
+__setup("nofaultaround", disable_fault_around);
+
/*
* do_fault_around() tries to map few pages around the fault address. The hope
* is that the pages will be needed soon and this will lower the number of
@@ -2965,7 +2973,8 @@ static int do_read_fault(struct mm_struct *mm, struct vm_area_struct *vma,
* if page by the offset is not ready to be mapped (cold cache or
* something).
*/
- if (vma->vm_ops->map_pages && !(flags & FAULT_FLAG_NONLINEAR) &&
+ if (enable_fault_around && vma->vm_ops->map_pages &&
+ !(flags & FAULT_FLAG_NONLINEAR) &&
fault_around_pages() > 1) {
pte = pte_offset_map_lock(mm, pmd, address, &ptl);
do_fault_around(vma, address, pte, pgoff, flags);
--
1.7.9.5
On Tue, 25 Nov 2014 15:51:58 +0900 Chanho Min <[email protected]> wrote:
> The faultaround improves the file read performance, whereas pages which
> can be dropped by drop_caches are reduced. On some systems, The amount of
> freeable pages under memory pressure is more important than read
> performance.
The faultaround pages *are* freeable. Perhaps you meant "free" here.
Please tell us a great deal about the problem which you are trying to
solve. What sort of system, what sort of workload, what is bad about
the behaviour which you are observing, etc.
On Tue, 25 Nov 2014 20:19:40 +0900 "Chanho Min" <[email protected]> wrote:
> > > The faultaround improves the file read performance, whereas pages which
> > > can be dropped by drop_caches are reduced. On some systems, The amount of
> > > freeable pages under memory pressure is more important than read
> > > performance.
> >
> > The faultaround pages *are* freeable. Perhaps you meant "free" here.
> >
> > Please tell us a great deal about the problem which you are trying to
> > solve. What sort of system, what sort of workload, what is bad about
> > the behaviour which you are observing, etc.
>
> We are trying to solve two issues.
>
> We drop page caches by writing to /proc/sys/vm/drop_caches at specific point
> and make suspend-to-disk image. The size of this image is increased if faultaround
> is worked.
OK.
These pages are clean (mostly) and are mapped into process pagetables.
Obviously mm/vmscan.c:shrink_all_memory() is not freeing these pages
prior to hibernating.
I forget what the policy/tuning is in this area. IIRC, the intent of
shrink_all_memory() is to free up enough memory so that hibernation can
perform its function, rather than to explicitly reduce the size of the
image.
What I suggest you do is to take a look at how hibernation is calling
shrink_all_memory() and retune it so it shrinks a lot harder. You may
want to disable swapping, or perhaps reduce it by performing one
shrink_all_memory() in the same way as at present, then perform a
second shrink_all_memory() more aggressively, but with
scan_control.may_swap=0. The overall effect will be to make
hibernation tear down the process pagetable mappings and free these
pagecache pages before preparing the disk image.
If we can get this working then your hibernation image will be
significantly smaller than it is with this patch, because more pages
will be unmapped and freed. There will of course be a lot of major
pagefaults after resume. If that's a problem then perhaps we can tune
the second shrink_all_memory() pass to only unmap ptes for unreferenced
pages.
> Under memory pressure, we want to drop many page caches as possible.
> But, The number of dropped pages are reduced compared to non-faultaround kernel.
Again, why do you want to do this? What problem is it solving? I
assume you're using drop_caches for this as well?
Generally, any use of drop_caches is wrong, and indicates there's some
shortcoming in MM.
On Tue, Nov 25, 2014 at 08:19:40PM +0900, Chanho Min wrote:
> > > The faultaround improves the file read performance, whereas pages which
> > > can be dropped by drop_caches are reduced. On some systems, The amount of
> > > freeable pages under memory pressure is more important than read
> > > performance.
> >
> > The faultaround pages *are* freeable. Perhaps you meant "free" here.
> >
> > Please tell us a great deal about the problem which you are trying to
> > solve. What sort of system, what sort of workload, what is bad about
> > the behaviour which you are observing, etc.
>
> We are trying to solve two issues.
>
> We drop page caches by writing to /proc/sys/vm/drop_caches at specific point
> and make suspend-to-disk image. The size of this image is increased if faultaround
> is worked.
drop_caches should never be used outside debugging process. If you use it
as part of usual workflow you're doing something wrong.
I'm not aware about details on how suspend-to-disk works, but I don't see
much point in saving page cache pages into suspend-to-disk image. Dirty
pages should be write out and we can read them back after resume on first
use. Possible exception is mlocked pages.
> Under memory pressure, we want to drop many page caches as possible.
> But, The number of dropped pages are reduced compared to non-faultaround kernel.
The reason why you see more pages in page cache after drop_pages with
faultaround enabled is that drop_pages doesn't touch mapped pages. And
with faultaround we obviously have more pages mapped.
It's not a reason to have faultaround disable. You should take a closer
look on suspend process.
--
Kirill A. Shutemov