On Sun, Jun 18, 2023 at 06:57:44AM +0000, Yosry Ahmed wrote:
> @@ -337,6 +318,7 @@ struct folio {
> atomic_t _entire_mapcount;
> atomic_t _nr_pages_mapped;
> atomic_t _pincount;
> + atomic_t _mlock_count;
> #ifdef CONFIG_64BIT
> unsigned int _folio_nr_pages;
> #endif
You can't quite do this. On 32-bt systems (I know, I know ...),
we have:
offset page 0 page 1
0 flags flags
4 lru head
8 lru dtor+order
12 mapping entire_mapcount
16 index nr_pages_napped
20 private pincount
24 mapcount
28 refcount
so it actually ends up overlapping page->mapcount on the second page,
which is of course used for counting the number of PTEs which map
that specific page.
I don't have a scenario where this would matter, but we are quite
careful to only allocate order-2+ large folios, so I'd suggest putting
it in page 2 instead of page 1.
I should probably add a comment to struct folio warning of this dragon.
I thought the #ifdef CONFIG_64BIT would be enough to warn unwary
passers-by of its presence, but a more explicit sign must be in order.
