On 17.02.24 03:25, Matthew Wilcox (Oracle) wrote:
By making release_pages() call folios_put(), we can get rid of the calls
to compound_head() for the callers that already know they have folios.
We can also get rid of the lock_batch tracking as we know the size
of the batch is limited by folio_batch. This does reduce the maximum
number of pages for which the lruvec lock is held, from SWAP_CLUSTER_MAX
(32) to PAGEVEC_SIZE (15). I do not expect this to make a significant
difference, but if it does, we can increase PAGEVEC_SIZE to 31.
I'm afraid that won't apply to current mm-unstable anymore, where we can
now put multiple references to a single folio (as part of unmapping
large PTE-mapped folios).
[...]
+/**
+ * release_pages - batched put_page()
+ * @arg: array of pages to release
+ * @nr: number of pages
+ *
+ * Decrement the reference count on all the pages in @arg. If it
+ * fell to zero, remove the page from the LRU and free it.
+ *
+ * Note that the argument can be an array of pages, encoded pages,
+ * or folio pointers. We ignore any encoded bits, and turn any of
+ * them into just a folio that gets free'd.
+ */
+void release_pages(release_pages_arg arg, int nr)
+{
+ struct folio_batch fbatch;
+ struct encoded_page **encoded = arg.encoded_pages;
+ int i;
+
+ folio_batch_init(&fbatch);
+ for (i = 0; i < nr; i++) {
+ /* Turn any of the argument types into a folio */
+ struct folio *folio = page_folio(encoded_page_ptr(encoded[i]));
+
As an "easy" way forward, we could handle these "multiple-ref" cases
here by putting ref-1 references, and leaving the single remaining
reference to folios_put().
That implies, more atomic operations, though.
Alternatively, "struct folio_batch" would have to be optimized to
understand "put multiple references" as well.
+ if (folio_batch_add(&fbatch, folio) > 0)
+ continue;
+ folios_put(&fbatch);
+ }
+
+ if (fbatch.nr)
+ folios_put(&fbatch);
}
EXPORT_SYMBOL(release_pages);
--
Cheers,
David / dhildenb
