From: Wei Wang <[email protected]>
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 <[email protected]>
---
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
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?
On Fri, Mar 16, 2018 at 11:25:08AM -0700, Wei Wang wrote:
> From: Wei Wang <[email protected]>
>
> 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 <[email protected]>
> ---
> 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
On Fri, Mar 16, 2018 at 1:56 PM, Kirill A. Shutemov
<[email protected]> 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
On Fri, 16 Mar 2018 11:25:08 -0700 Wei Wang <[email protected]> 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?
On Fri, 16 Mar 2018 21:51:48 +0000 Wei Wang <[email protected]> wrote:
> On Fri, Mar 16, 2018, 14:33 Andrew Morton <[email protected]> wrote:
>
> > On Fri, 16 Mar 2018 11:25:08 -0700 Wei Wang <[email protected]> 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.
On Fri, Mar 16, 2018 at 2:59 PM Andrew Morton <[email protected]>
wrote:
> On Fri, 16 Mar 2018 21:51:48 +0000 Wei Wang <[email protected]>
wrote:
> > On Fri, Mar 16, 2018, 14:33 Andrew Morton <[email protected]>
wrote:
> >
> > > On Fri, 16 Mar 2018 11:25:08 -0700 Wei Wang <[email protected]> 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.
Wei Wang <[email protected]> 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
On Sun, Mar 18, 2018 at 7:37 PM Huang, Ying <[email protected]> wrote:
> Wei Wang <[email protected]> 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
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 <[email protected]> wrote:
>
> From: Wei Wang <[email protected]>
>
> 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 <[email protected]>
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 <[email protected]>
SUSE Labs, CR