Messages in this thread | | | Subject | Re: [RFC PATCH] mm: readahead: add readahead_shift into backing device | From | Mark Salyzyn <> | Date | Mon, 25 Mar 2019 09:59:31 -0700 |
| |
On 03/25/2019 05:16 AM, Fengguang Wu wrote: > Martin, > > On Fri, Mar 22, 2019 at 11:46:11PM +0800, Martin Liu wrote: >> As the discussion https://lore.kernel.org/patchwork/patch/334982/ >> We know an open file's ra_pages might run out of sync from >> bdi.ra_pages since sequential, random or error read. Current design >> is we have to ask users to reopen the file or use fdavise system >> call to get it sync. However, we might have some cases to change >> system wide file ra_pages to enhance system performance such as >> enhance the boot time by increasing the ra_pages or decrease it to > > Do you have examples that some distro making use of larger ra_pages > for boot time optimization?
Android (if you are willing to squint and look at android-common AOSP kernels as a Distro).
> > Suppose N read streams with equal read speed. The thrash-free memory > requirement would be (N * 2 * ra_pages). > > If N=1000 and ra_pages=1MB, it'd require 2GB memory. Which looks > affordable in mainstream servers. That is 50% of the memory on a high end Android device ... > > Sorry but it sounds like introducing an unnecessarily twisted new > interface. I'm afraid it fixes the pain for 0.001% users while > bringing more puzzle to the majority others. >2B Android devices on the planet is 0.001%?
I am not defending the proposed interface though, if there is something better that can be used, then looking into: > > Then let fadvise() and shrink_readahead_size_eio() adjust that > per-file ra_pages_shift. Sounds like this would require a lot from init to globally audit and reduce the read-ahead for all open files?
Sincerely -- Mark Salyzyn
| |