linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Will Deacon <will.deacon@arm.com>
To: Mark Salyzyn <salyzyn@android.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Riley Andrews <riandrews@android.com>,
	Shaohua Li <shli@kernel.org>,
	Shaohua Li <shaohua.li@fusionio.com>,
	Rik van Riel <riel@redhat.com>,
	Wu Fengguang <fengguang.wu@intel.com>,
	Catalin Marinas <Catalin.Marinas@arm.com>,
	Vladimir Murzin <Vladimir.Murzin@arm.com>,
	Dave P Martin <Dave.Martin@arm.com>,
	David Hildenbrand <dahi@linux.vnet.ibm.com>,
	James Morse <James.Morse@arm.com>,
	Mark Rutland <Mark.Rutland@arm.com>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: ARM64 readahead: fault retry breaks mmap file read random detection
Date: Mon, 21 Sep 2015 22:09:38 +0100	[thread overview]
Message-ID: <20150921210938.GC7356@arm.com> (raw)
In-Reply-To: <1442868028-27055-1-git-send-email-salyzyn@android.com>

On Mon, Sep 21, 2015 at 09:39:50PM +0100, Mark Salyzyn wrote:
> Description from commit 45cac65b0fcd
>     ("readahead: fault retry breaks mmap file read random detection")
> 
> .fault now can retry.  The retry can break state machine of .fault.  In
> filemap_fault, if page is miss, ra->mmap_miss is increased.  In the second
> try, since the page is in page cache now, ra->mmap_miss is decreased.  And
> these are done in one fault, so we can't detect random mmap file access.
> 
> Add a new flag to indicate .fault is tried once.  In the second try, skip
> ra->mmap_miss decreasing.  The filemap_fault state machine is ok with it.
> 
> I only tested x86, didn't test other archs, but looks the change for other
> archs is obvious, but who knows :)
> 
> < snip >
> 
> Yup, arm64 needs this too! Random read improves by 250%, sequential
> read improves by 40%, and random write by 400% to an eMMC device with
> dm crypto wrapped around it.

Thanks for this. This must've gone in whilst we were developing the initial
version of the arm64 port and has since gone unnoticed.

I'll queue it on the arm64 fixes branch and send a pull request after
some testing.

Will

  reply	other threads:[~2015-09-21 21:09 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-21 20:39 ARM64 readahead: fault retry breaks mmap file read random detection Mark Salyzyn
2015-09-21 21:09 ` Will Deacon [this message]
2015-09-21 21:36   ` Mark Salyzyn
2015-09-21 23:51     ` Will Deacon
2015-09-22 14:15       ` Mark Salyzyn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150921210938.GC7356@arm.com \
    --to=will.deacon@arm.com \
    --cc=Catalin.Marinas@arm.com \
    --cc=Dave.Martin@arm.com \
    --cc=James.Morse@arm.com \
    --cc=Mark.Rutland@arm.com \
    --cc=Vladimir.Murzin@arm.com \
    --cc=dahi@linux.vnet.ibm.com \
    --cc=fengguang.wu@intel.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=riandrews@android.com \
    --cc=riel@redhat.com \
    --cc=salyzyn@android.com \
    --cc=shaohua.li@fusionio.com \
    --cc=shli@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).