add static huge zero folio support#49
add static huge zero folio support#49blktests-ci[bot] wants to merge 5 commits intolinus-master_basefrom
Conversation
|
Upstream branch: 89be9a8 |
81f31a4 to
87bbbbc
Compare
|
Upstream branch: 25fae0b |
d3badf4 to
2ba5189
Compare
87bbbbc to
6637119
Compare
|
Upstream branch: 14bed9b |
2ba5189 to
78181d5
Compare
6637119 to
f092a9b
Compare
|
Upstream branch: 260f6f4 |
78181d5 to
e9533f8
Compare
f092a9b to
0b59764
Compare
|
Upstream branch: d6084bb |
e9533f8 to
b59f676
Compare
0b59764 to
aee5bd3
Compare
|
Upstream branch: 831462f |
b59f676 to
1652f6a
Compare
aee5bd3 to
ef18525
Compare
|
Upstream branch: c93529a |
1652f6a to
5457f95
Compare
ef18525 to
3851b3f
Compare
|
Upstream branch: cbbf0a7 |
5457f95 to
c481bd3
Compare
3851b3f to
28b3384
Compare
|
Upstream branch: 6a68cec |
c481bd3 to
73e0c18
Compare
33f001b to
e9bcc53
Compare
37dce65 to
4c26e9a
Compare
|
Upstream branch: 71a0760 |
e9bcc53 to
c639696
Compare
4c26e9a to
1356209
Compare
|
Upstream branch: 2988dfe |
c639696 to
255faf2
Compare
1356209 to
ae9bce3
Compare
|
Upstream branch: c30a135 |
255faf2 to
f5e112b
Compare
ae9bce3 to
e263d6e
Compare
|
Upstream branch: 561c803 |
|
Upstream branch: b96ddbc |
|
Upstream branch: 2b38afc |
|
Upstream branch: 8f5ae30 |
|
Upstream branch: 53e760d |
|
Upstream branch: 0e39a73 |
|
Upstream branch: 8742b2d |
|
Upstream branch: 91325f3 |
|
Upstream branch: 3a4a036 |
|
Upstream branch: dfc0f63 |
|
Upstream branch: 0cc5352 |
|
Upstream branch: 24ea63e |
|
Upstream branch: d7ee5bd |
|
Upstream branch: b19a97d |
As we already moved from exposing huge_zero_page to huge_zero_folio, change the name of the shrinker and the other helper function to reflect that. No functional changes. Reviewed-by: Lorenzo Stoakes <[email protected]> Suggested-by: David Hildenbrand <[email protected]> Acked-by: David Hildenbrand <[email protected]> Signed-off-by: Pankaj Raghav <[email protected]>
As all the helper functions has been renamed from *_page to *_folio, rename the MM flag from MMF_HUGE_ZERO_PAGE to MMF_HUGE_ZERO_FOLIO. No functional changes. Suggested-by: David Hildenbrand <[email protected]> Signed-off-by: Pankaj Raghav <[email protected]> Reviewed-by: Lorenzo Stoakes <[email protected]> Acked-by: David Hildenbrand <[email protected]> Reviewed-by: Zi Yan <[email protected]>
There are many places in the kernel where we need to zeroout larger chunks but the maximum segment we can zeroout at a time by ZERO_PAGE is limited by PAGE_SIZE. This is especially annoying in block devices and filesystems where we attach multiple ZERO_PAGEs to the bio in different bvecs. With multipage bvec support in block layer, it is much more efficient to send out larger zero pages as a part of single bvec. This concern was raised during the review of adding LBS support to XFS[1][2]. Usually huge_zero_folio is allocated on demand, and it will be deallocated by the shrinker if there are no users of it left. At moment, huge_zero_folio infrastructure refcount is tied to the process lifetime that created it. This might not work for bio layer as the completions can be async and the process that created the huge_zero_folio might no longer be alive. And, one of the main point that came during discussion is to have something bigger than zero page as a drop-in replacement. Add a config option STATIC_HUGE_ZERO_FOLIO that will result in allocating the huge zero folio on first request, if not already allocated, and turn it static such that it can never get freed. This makes using the huge_zero_folio without having to pass any mm struct and does not tie the lifetime of the zero folio to anything, making it a drop-in replacement for ZERO_PAGE. If STATIC_HUGE_ZERO_FOLIO config option is enabled, then mm_get_huge_zero_folio() will simply return this page instead of dynamically allocating a new PMD page. This option can waste memory in small systems or systems with 64k base page size. So make it an opt-in and also add an option from individual architecture so that we don't enable this feature for larger base page size systems. Only x86 is enabled as a part of this series. Other architectures shall be enabled as a follow-up to this series. [1] https://lore.kernel.org/linux-xfs/[email protected]/ [2] https://lore.kernel.org/linux-xfs/[email protected]/ Co-developed-by: David Hildenbrand <[email protected]> Signed-off-by: David Hildenbrand <[email protected]> Signed-off-by: Pankaj Raghav <[email protected]>
Add largest_zero_folio() routine so that huge_zero_folio can be used directly when CONFIG_STATIC_HUGE_ZERO_FOLIO is enabled. This will return ZERO_PAGE folio if CONFIG_STATIC_HUGE_ZERO_FOLIO is disabled or if we failed to allocate a huge_zero_folio. Co-developed-by: David Hildenbrand <[email protected]> Signed-off-by: David Hildenbrand <[email protected]> Signed-off-by: Pankaj Raghav <[email protected]> Reviewed-by: Lorenzo Stoakes <[email protected]> Reviewed-by: Zi Yan <[email protected]>
Use largest_zero_folio() in __blkdev_issue_zero_pages(). On systems with CONFIG_STATIC_HUGE_ZERO_FOLIO enabled, we will end up sending larger bvecs instead of multiple small ones. Noticed a 4% increase in performance on a commercial NVMe SSD which does not support OP_WRITE_ZEROES. The device's MDTS was 128K. The performance gains might be bigger if the device supports bigger MDTS. Signed-off-by: Pankaj Raghav <[email protected]> Acked-by: Lorenzo Stoakes <[email protected]>
Pull request for series with
subject: add static huge zero folio support
version: 1
url: https://patchwork.kernel.org/project/linux-block/list/?series=984633