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
