LU-17081 build: Prefer folio_batch to pagevec
Linux commit v5.16-rc4-36-g10331795fb79
pagevec: Add folio_batch
Linux commit v6.2-rc4-254-g811561288397
mm: pagevec: add folio_batch_reinit()
Linux commit v6.4-rc4-438-g1e0877d58b1e
mm: remove struct pagevec
Use folio_batch and provide wrappers for older kernels to use
pagevec handling, conditionally provide a folio_batch_reinit
Add macros to ease adding pages to folio_batch(es) as well
as unwinding batches of struct folio where struct page is
needed.
Lustre-change: https://review.whamcloud.com/52259
Lustre-commit:
b82eab822c078b584fadefd419bfa74df0edebcb
Was-Change-Id: Ie70e4851df00a73f194aaa6631678b54b5d128a1
LU-17904 build: fix typo in vvp_set_batch_dirty
Fix typo vvp_set_batch_dirty() when kallsyms_lookup_name()
is exported and account_page_dirtied is not.
HPE-bug-id: LUS-12374
Fixes:
b82eab822c0 ("LU-17081 build: Prefer folio_batch to pagevec")
Lustre-change: https://review.whamcloud.com/55301
Lustre-commit:
a89458b3b2a08f78c4795816ca34716b110b8aac
Was-Change-Id: I8b2e6884e74e384aba6e563bef30072175cc0efc
LU-17903 build: enable fast path of vvp_set_batch_dirty
SUSE 15 SP6 6.4 kernel retains kallsyms_lookup_name so
the fast path of vvp_set_batch_dirty() can be enabled.
However the combination of kallsyms_lookup_name without
lock_page_memcg breaks some old assumptions
Prefer folio_memcg_lock to lock_page_memcg however
Linux commit v5.15-12272-g913ffbdd9985
mm: unexport folio_memcg_{,un}lock
folio_memcg_lock is also not exported so use
kallsyms_lookup_name to acquire the symbol
HPE-bug-id: LUS-12371
Fixes:
61e83a6f130 ("LU-16113 build: Fix configure tests for lock_page_memcg")
Lustre-change: https://review.whamcloud.com/55300
Lustre-commit:
ac6dba062928c3eba5f2ddd372a6225436b4e96a
Was-Change-Id: I8ac6b7bde8ee8964db5a801c2f3c4dfb2ef459f9
HPE-bug-id: LUS-11811
Signed-off-by: Shaun Tancheff <shaun.tancheff@hpe.com>
Change-Id: Ie70e4851df00a73f194aaa6631678b54b5d128a1
Reviewed-on: https://review.whamcloud.com/c/fs/lustre-release/+/59099
Tested-by: jenkins <devops@whamcloud.com>
Tested-by: Maloo <maloo@whamcloud.com>
Reviewed-by: Yang Sheng <ys@whamcloud.com>
Reviewed-by: Oleg Drokin <green@whamcloud.com>