[PATCH] mm: add config for readahead window

[PATCH] mm: add config for readahead window

[Wei Wang]

From: Wei Wang <wvw@google.com>

Change VM_MAX_READAHEAD value from the default 128KB to a configurable
value. This will allow the readahead window to grow to a maximum size
bigger than 128KB during boot, which could benefit to sequential read
throughput and thus boot performance.

Signed-off-by: Wei Wang <wvw@google.com>
---
 include/linux/mm.h | 2 +-
 mm/Kconfig         | 8 ++++++++
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index ad06d42adb1a..d7dc6125833e 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2291,7 +2291,7 @@ int __must_check write_one_page(struct page *page);
 void task_dirty_inc(struct task_struct *tsk);
 
 /* readahead.c */
-#define VM_MAX_READAHEAD	128	/* kbytes */
+#define VM_MAX_READAHEAD	CONFIG_VM_MAX_READAHEAD_KB
 #define VM_MIN_READAHEAD	16	/* kbytes (includes current page) */
 
 int force_page_cache_readahead(struct address_space *mapping, struct file *filp,
diff --git a/mm/Kconfig b/mm/Kconfig
index c782e8fb7235..da9ff543bdb9 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -760,3 +760,11 @@ config GUP_BENCHMARK
 	  performance of get_user_pages_fast().
 
 	  See tools/testing/selftests/vm/gup_benchmark.c
+
+config VM_MAX_READAHEAD_KB
+	int "Default max readahead window size in Kilobytes"
+	default 128
+	help
+	  This sets the VM_MAX_READAHEAD value to allow the readahead window
+	  to grow to a maximum size of configured. Increasing this value will
+	  benefit sequential read throughput.
-- 
2.16.2.804.g6dcf76e118-goog

Re: [PATCH] mm: add config for readahead window

[Wei Wang]

[-- Attachment #1: Type: text/plain, Size: 1941 bytes --]

Android devices boot time benefits by bigger readahead window setting from
init. This patch will make readahead window a config so early boot can
benefit by it as well.


On Fri, Mar 16, 2018 at 11:25 AM Wei Wang <wvw@google.com> wrote:

> From: Wei Wang <wvw@google.com>
>
> Change VM_MAX_READAHEAD value from the default 128KB to a configurable
> value. This will allow the readahead window to grow to a maximum size
> bigger than 128KB during boot, which could benefit to sequential read
> throughput and thus boot performance.
>
> Signed-off-by: Wei Wang <wvw@google.com>
> ---
>  include/linux/mm.h | 2 +-
>  mm/Kconfig         | 8 ++++++++
>  2 files changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index ad06d42adb1a..d7dc6125833e 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -2291,7 +2291,7 @@ int __must_check write_one_page(struct page *page);
>  void task_dirty_inc(struct task_struct *tsk);
>
>  /* readahead.c */
> -#define VM_MAX_READAHEAD       128     /* kbytes */
> +#define VM_MAX_READAHEAD       CONFIG_VM_MAX_READAHEAD_KB
>  #define VM_MIN_READAHEAD       16      /* kbytes (includes current page)
> */
>
>  int force_page_cache_readahead(struct address_space *mapping, struct file
> *filp,
> diff --git a/mm/Kconfig b/mm/Kconfig
> index c782e8fb7235..da9ff543bdb9 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -760,3 +760,11 @@ config GUP_BENCHMARK
>           performance of get_user_pages_fast().
>
>           See tools/testing/selftests/vm/gup_benchmark.c
> +
> +config VM_MAX_READAHEAD_KB
> +       int "Default max readahead window size in Kilobytes"
> +       default 128
> +       help
> +         This sets the VM_MAX_READAHEAD value to allow the readahead
> window
> +         to grow to a maximum size of configured. Increasing this value
> will
> +         benefit sequential read throughput.
> --
> 2.16.2.804.g6dcf76e118-goog
>
>

[-- Attachment #2: Type: text/html, Size: 2908 bytes --]

Re: [PATCH] mm: add config for readahead window

[Greg KH]

On Fri, Mar 16, 2018 at 06:49:08PM +0000, Wei Wang wrote:
> Android devices boot time benefits by bigger readahead window setting from
> init. This patch will make readahead window a config so early boot can
> benefit by it as well.

Why not put that in the changelog text?

Re: [PATCH] mm: add config for readahead window

[Huang, Ying]

Wei Wang <wvw@google.com> writes:

> Android devices boot time benefits by bigger readahead window setting from
> init. This patch will make readahead window a config so early boot can
> benefit by it as well.

Can you change the source code of init to call ioctl(BLKRASET) early?

Best Regards,
Huang, Ying

Re: [PATCH] mm: add config for readahead window

[Wei Wang]

On Sun, Mar 18, 2018 at 7:37 PM Huang, Ying <ying.huang@intel.com> wrote:

> Wei Wang <wvw@google.com> writes:

> > Android devices boot time benefits by bigger readahead window setting
from
> > init. This patch will make readahead window a config so early boot can
> > benefit by it as well.

> Can you change the source code of init to call ioctl(BLKRASET) early?

> Best Regards,
> Huang, Ying

Yes, I am sure we can work this out by not touching it in mainline kernel.
One reason to bring it up again is that we found some SoC vendor has always
set a different value than default (128) in their kernel tree.

Thanks,
Wei Wang

Re: [PATCH] mm: add config for readahead window

[Jan Kara]

On Fri 16-03-18 18:49:08, Wei Wang wrote:
> Android devices boot time benefits by bigger readahead window setting from
> init. This patch will make readahead window a config so early boot can benefit
> by it as well.
> 
> 
> On Fri, Mar 16, 2018 at 11:25 AM Wei Wang <wvw@google.com> wrote:
> 
>     From: Wei Wang <wvw@google.com>
> 
>     Change VM_MAX_READAHEAD value from the default 128KB to a configurable
>     value. This will allow the readahead window to grow to a maximum size
>     bigger than 128KB during boot, which could benefit to sequential read
>     throughput and thus boot performance.
> 
>     Signed-off-by: Wei Wang <wvw@google.com>

Just for record we had VM_MAX_READAHEAD changed to 512 in all SUSE
distributions for quite some years. But just recently we were re-evaluating
it and we are finding less and less reasons to keep this setting to 512 -
with newer storage benefits become marginal and the overhead of reading
more unnecessarily in some other corner cases is visible as well (I still
have somewhere reports from 0-day robot that complained to me about two
performance regressions coming from increased default readahead window).

So for your specific case it might make sense to increase the window when
you have a control of both the HW and the kernel but in general I tend to
currently agree with Linus & co. that the current default is probably fine.

I don't have a strong opinion on whether your ~90ms of boot time are good
enough justification for a kernel config option...

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: [PATCH] mm: add config for readahead window

[Kirill A. Shutemov]

On Fri, Mar 16, 2018 at 11:25:08AM -0700, Wei Wang wrote:
> From: Wei Wang <wvw@google.com>
> 
> Change VM_MAX_READAHEAD value from the default 128KB to a configurable
> value. This will allow the readahead window to grow to a maximum size
> bigger than 128KB during boot, which could benefit to sequential read
> throughput and thus boot performance.

Increase of readahead window was proposed several times. And rejected.
IIRC, Linus was against it.

What is different this time?

> Signed-off-by: Wei Wang <wvw@google.com>
> ---
>  include/linux/mm.h | 2 +-
>  mm/Kconfig         | 8 ++++++++
>  2 files changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index ad06d42adb1a..d7dc6125833e 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -2291,7 +2291,7 @@ int __must_check write_one_page(struct page *page);
>  void task_dirty_inc(struct task_struct *tsk);
>  
>  /* readahead.c */
> -#define VM_MAX_READAHEAD	128	/* kbytes */
> +#define VM_MAX_READAHEAD	CONFIG_VM_MAX_READAHEAD_KB
>  #define VM_MIN_READAHEAD	16	/* kbytes (includes current page) */
>  
>  int force_page_cache_readahead(struct address_space *mapping, struct file *filp,
> diff --git a/mm/Kconfig b/mm/Kconfig
> index c782e8fb7235..da9ff543bdb9 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -760,3 +760,11 @@ config GUP_BENCHMARK
>  	  performance of get_user_pages_fast().
>  
>  	  See tools/testing/selftests/vm/gup_benchmark.c
> +
> +config VM_MAX_READAHEAD_KB
> +	int "Default max readahead window size in Kilobytes"
> +	default 128
> +	help
> +	  This sets the VM_MAX_READAHEAD value to allow the readahead window
> +	  to grow to a maximum size of configured. Increasing this value will
> +	  benefit sequential read throughput.
> -- 
> 2.16.2.804.g6dcf76e118-goog
> 

-- 
 Kirill A. Shutemov

Re: [PATCH] mm: add config for readahead window

[Linus Torvalds]

On Fri, Mar 16, 2018 at 1:56 PM, Kirill A. Shutemov
<kirill@shutemov.name> wrote:
>
> Increase of readahead window was proposed several times. And rejected.
> IIRC, Linus was against it.

I have never seen any valid situation that wasn't tuning for one odd
machine, usually with a horribly crappy disk setup and very little
testing of latencies or low-memory situations.

And "horribly crappy" very much tends to include "big serious
enterprise hardware" that people paid big bucks for, and that has huge
theoretical throughput for large transfers, but is pure garbage in
every other way.

So I'm still very much inclined against these kinds of things. They
need *extensive* numbers and explanations for why it's not just some
uncommon thing for one setup.

                   Linus

Re: [PATCH] mm: add config for readahead window

[Andrew Morton]

On Fri, 16 Mar 2018 11:25:08 -0700 Wei Wang <wvw@google.com> wrote:

> Change VM_MAX_READAHEAD value from the default 128KB to a configurable
> value. This will allow the readahead window to grow to a maximum size
> bigger than 128KB during boot, which could benefit to sequential read
> throughput and thus boot performance.

You can presently run ioctl(BLKRASET) against the block device?

Re: [PATCH] mm: add config for readahead window

[Wei Wang]

[-- Attachment #1: Type: text/plain, Size: 603 bytes --]

On Fri, Mar 16, 2018, 14:33 Andrew Morton <akpm@linux-foundation.org> wrote:

> On Fri, 16 Mar 2018 11:25:08 -0700 Wei Wang <wvw@google.com> wrote:
>
> > Change VM_MAX_READAHEAD value from the default 128KB to a configurable
> > value. This will allow the readahead window to grow to a maximum size
> > bigger than 128KB during boot, which could benefit to sequential read
> > throughput and thus boot performance.
>
> You can presently run ioctl(BLKRASET) against the block device?
>

Yeah we are doing tuning in userland after init. But this is something we
thought could help in very early stage.

>

[-- Attachment #2: Type: text/html, Size: 1190 bytes --]

Re: [PATCH] mm: add config for readahead window

[Andrew Morton]

On Fri, 16 Mar 2018 21:51:48 +0000 Wei Wang <wei.vince.wang@gmail.com> wrote:

> On Fri, Mar 16, 2018, 14:33 Andrew Morton <akpm@linux-foundation.org> wrote:
> 
> > On Fri, 16 Mar 2018 11:25:08 -0700 Wei Wang <wvw@google.com> wrote:
> >
> > > Change VM_MAX_READAHEAD value from the default 128KB to a configurable
> > > value. This will allow the readahead window to grow to a maximum size
> > > bigger than 128KB during boot, which could benefit to sequential read
> > > throughput and thus boot performance.
> >
> > You can presently run ioctl(BLKRASET) against the block device?
> >
> 
> Yeah we are doing tuning in userland after init. But this is something we
> thought could help in very early stage.
> 

"thought" and "could" are rather weak!  Some impressive performance
numbers for real-world setups would help such a patch along.

Re: [PATCH] mm: add config for readahead window

[Wei Wang]

On Fri, Mar 16, 2018 at 2:59 PM Andrew Morton <akpm@linux-foundation.org>
wrote:

> On Fri, 16 Mar 2018 21:51:48 +0000 Wei Wang <wei.vince.wang@gmail.com>
wrote:

> > On Fri, Mar 16, 2018, 14:33 Andrew Morton <akpm@linux-foundation.org>
wrote:
> >
> > > On Fri, 16 Mar 2018 11:25:08 -0700 Wei Wang <wvw@google.com> wrote:
> > >
> > > > Change VM_MAX_READAHEAD value from the default 128KB to a
configurable
> > > > value. This will allow the readahead window to grow to a maximum
size
> > > > bigger than 128KB during boot, which could benefit to sequential
read
> > > > throughput and thus boot performance.
> > >
> > > You can presently run ioctl(BLKRASET) against the block device?
> > >
> >
> > Yeah we are doing tuning in userland after init. But this is something
we
> > thought could help in very early stage.
> >

> "thought" and "could" are rather weak!  Some impressive performance
> numbers for real-world setups would help such a patch along.

~90ms savings from an Android device compared to setting the window later
in userland.
I was using 'week' words as I agree with Linus's point - it is all about
the storage, so the savings are not universal indeed.