Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1229726 > unrolled thread

ARM64 readahead: fault retry breaks mmap file read random detection

Back to article view | Back to linux.kernel

Contents

  ARM64 readahead: fault retry breaks mmap file read random detection Mark Salyzyn <salyzyn@android.com> - 2015-09-21 22:50 +0200
    Re: ARM64 readahead: fault retry breaks mmap file read random  detection Will Deacon <will.deacon@arm.com> - 2015-09-21 23:10 +0200
      Re: ARM64 readahead: fault retry breaks mmap file read random  detection Mark Salyzyn <salyzyn@android.com> - 2015-09-21 23:40 +0200
        Re: ARM64 readahead: fault retry breaks mmap file read random  detection Will Deacon <will.deacon@arm.com> - 2015-09-22 02:00 +0200
          Re: ARM64 readahead: fault retry breaks mmap file read random  detection Mark Salyzyn <salyzyn@android.com> - 2015-09-22 16:20 +0200

#1229726 — ARM64 readahead: fault retry breaks mmap file read random detection

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.

Signed-off-by: Mark Salyzyn <salyzyn@android.com>
Signed-off-by: Riley Andrews <riandrews@android.com>
Cc: Shaohua Li <shli@kernel.org>
Cc: Shaohua Li <shaohua.li@fusionio.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Wu Fengguang <fengguang.wu@intel.com>
---
 arch/arm64/mm/fault.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index aba9ead..9fadf6d 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -287,6 +287,7 @@ retry:
 			 * starvation.
 			 */
 			mm_flags &= ~FAULT_FLAG_ALLOW_RETRY;
+			mm_flags |= FAULT_FLAG_TRIED;
 			goto retry;
 		}
 	}
-- 
2.6.0.rc0.131.gf624c3d

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1229738 — Re: ARM64 readahead: fault retry breaks mmap file read random detection

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1229764 — Re: ARM64 readahead: fault retry breaks mmap file read random detection

On 09/21/2015 02:09 PM, Will Deacon wrote:
> 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")
>> . . .
>> 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

As noted, this fix may need to be propagated to all the arch-specific 
code, I was not in a position to check this out on arm (32 bit) and the 
benchmarking code I used did not immediately port to 32-bit.

Sincerely -- Mark Salyzyn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1229839 — Re: ARM64 readahead: fault retry breaks mmap file read random detection

On Mon, Sep 21, 2015 at 10:36:40PM +0100, Mark Salyzyn wrote:
> On 09/21/2015 02:09 PM, Will Deacon wrote:
> > 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")
> >> . . .
> >> 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.
> >
> As noted, this fix may need to be propagated to all the arch-specific 
> code, I was not in a position to check this out on arm (32 bit) and the 
> benchmarking code I used did not immediately port to 32-bit.

You lost me; which arch-specific code are you referring to? The original
patch (in mainline) touches a whole bunch of architectures.

Will
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1230251 — Re: ARM64 readahead: fault retry breaks mmap file read random detection

On 09/21/2015 04:51 PM, Will Deacon wrote:
> On Mon, Sep 21, 2015 at 10:36:40PM +0100, Mark Salyzyn wrote:
>> On 09/21/2015 02:09 PM, Will Deacon wrote:
>>> 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")
>>>> . . .
>>>> 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.
>>>
>> As noted, this fix may need to be propagated to all the arch-specific
>> code, I was not in a position to check this out on arm (32 bit) and the
>> benchmarking code I used did not immediately port to 32-bit.
> You lost me; which arch-specific code are you referring to? The original
> patch (in mainline) touches a whole bunch of architectures.
>
> Will
I see I am mistaken, arm64 was the _only_ one I see that is missing ... 
<grin>

Sincerely -- Mark Salyzyn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web