linux-kernel - [bug report] read-ahead can't work properly

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <37a8bb5a.af8b.16b89adff5d.Coremail.weijieut@163.com>
Date:   Mon, 24 Jun 2019 21:30:10 +0800 (CST)
From:   "Weijie Yang" <weijieut@....com>
To:     linux-kernel@...r.kernel.org, linux-mm@...ck.org
Cc:     axboe@...com, fengguang.wu@...el.com, linux-api@...r.kernel.org,
        "weijie.yang@...sung.com" <weijie.yang@...sung.com>
Subject: [bug report] read-ahead can't work properly

When try the file readahead by posix_fadvise(), I find it can't work properly.

For example, posix_fadvise(POSIX_FADV_WILLNEED) a 10MB file, the kernel
actually  readahead only 512KB data to the page cache, even if there are enough
free memory in the machine.

When trace to kernel, I find the issue is at force_page_cache_readahead():

        max_pages = max_t(unsigned long, bdi->io_pages, ra->ra_pages);
        nr_to_read = min(nr_to_read, max_pages);

No mater what input nr_to_read is, it is limited to a very small size, such as 128 pages.

I think the min() limit code is to limit per-disk-io size, not the total nr_to_read.
and trace the git log, this issue is introduced by 6d2be915e589
after that, nr_to_read is limited at small, even if there are enough free memory.
before that, user can readahead a very large file if they have enough memory.

When read the posix_fadvise() man-page, it says readahead data depending on
virtual memory load. 
So if there are enough memory, it should read as many data as user expected.

Expect someone can clarify or/and fix it. 

Thanks