linux-kernel - Re: [GIT PULL] Two folio fixes for 5.18

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20220510151809.f06c7580af34221c16003264@linux-foundation.org>
Date:   Tue, 10 May 2022 15:18:09 -0700
From:   Andrew Morton <akpm@...ux-foundation.org>
To:     Matthew Wilcox <willy@...radead.org>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>, linux-mm@...ck.org,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] Two folio fixes for 5.18

On Fri, 6 May 2022 00:43:18 +0100 Matthew Wilcox <willy@...radead.org> wrote:

>  - Fix readahead creating single-page folios instead of the intended
>    large folios when doing reads that are not a power of two in size.

I worry about the idea of using hugepages in readahead.  We're
increasing the load on the hugepage allocator, which is already
groaning under the load.

The obvious risk is that handing out hugepages to a low-value consumer
(copying around pagecache which is only ever accessed via the direct
map) will deny their availability to high-value consumers (that
compute-intensive task against a large dataset).

Has testing and instrumentation been used to demonstrate that this is
not actually going to be a problem, or are we at risk of getting
unhappy reports?