+ mm-filemap-only-do-access-activations-on-reads.patch tentatively added to -mm tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



The patch titled
     Subject: mm: filemap: only do access activations on reads
has been added to the -mm tree.  Its filename is
     mm-filemap-only-do-access-activations-on-reads.patch

This patch should soon appear at
    http://ozlabs.org/~akpm/mmots/broken-out/mm-filemap-only-do-access-activations-on-reads.patch
and later at
    http://ozlabs.org/~akpm/mmotm/broken-out/mm-filemap-only-do-access-activations-on-reads.patch

Before you just go and hit "reply", please:
   a) Consider who else should be cc'ed
   b) Prefer to cc a suitable mailing list as well
   c) Ideally: find the original patch on the mailing list and do a
      reply-to-all to that, adding suitable additional cc's

*** Remember to use Documentation/SubmitChecklist when testing your code ***

The -mm tree is included into linux-next and is updated
there every 3-4 working days

------------------------------------------------------
From: Johannes Weiner <hannes@xxxxxxxxxxx>
Subject: mm: filemap: only do access activations on reads

Andres observed that his database workload is struggling with the
transaction journal creating pressure on frequently read pages.

Access patterns like transaction journals frequently write the same pages
over and over, but in the majority of cases those pages are never read
back.  There are no caching benefits to be had for those pages, so
activating them and having them put pressure on pages that do benefit from
caching is a bad choice.

Leave page activations to read accesses and don't promote pages based on
writes alone.

It could be said that partially written pages do contain cache-worthy
data, because even if *userspace* does not access the unwritten part, the
kernel still has to read it from the filesystem for correctness.  However,
a counter argument is that these pages enjoy at least *some* protection
over other inactive file pages through the writeback cache, in the sense
that dirty pages are written back with a delay and cache reclaim leaves
them alone until they have been written back to disk.  Should that turn
out to be insufficient and we see increased read IO from partial writes
under memory pressure, we can always go back and update
grab_cache_page_write_begin() to take (pos, len) so that it can tell
partial writes from pages that don't need partial reads.  But for now,
keep it simple.

Signed-off-by: Johannes Weiner <hannes@xxxxxxxxxxx>
Reported-by: Andres Freund <andres@xxxxxxxxxxx>
Cc: Rik van Riel <riel@xxxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---

 mm/filemap.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff -puN mm/filemap.c~mm-filemap-only-do-access-activations-on-reads mm/filemap.c
--- a/mm/filemap.c~mm-filemap-only-do-access-activations-on-reads
+++ a/mm/filemap.c
@@ -2579,7 +2579,7 @@ struct page *grab_cache_page_write_begin
 					pgoff_t index, unsigned flags)
 {
 	struct page *page;
-	int fgp_flags = FGP_LOCK|FGP_ACCESSED|FGP_WRITE|FGP_CREAT;
+	int fgp_flags = FGP_LOCK|FGP_WRITE|FGP_CREAT;
 
 	if (flags & AOP_FLAG_NOFS)
 		fgp_flags |= FGP_NOFS;
_

Patches currently in -mm which might be from hannes@xxxxxxxxxxx are

mm-filemap-only-do-access-activations-on-reads.patch

--
To unsubscribe from this list: send the line "unsubscribe mm-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Kernel Newbies FAQ]     [Kernel Archive]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [Bugtraq]     [Photo]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]

  Powered by Linux