On 26.06.24 06:41, Sergey Senozhatsky wrote:
On (24/06/25 15:33), Andrew Morton wrote:
On Fri, 31 May 2024 16:32:04 +0200 David Hildenbrand <david@xxxxxxxxxx> wrote:
On 31.05.24 16:27, Matthew Wilcox wrote:
On Thu, May 30, 2024 at 02:01:23PM +0900, Sergey Senozhatsky wrote:
1409: 83 c0 01 add $0x1,%eax
if (mapcount < PAGE_MAPCOUNT_RESERVE + 1)
140c: 83 f8 81 cmp $0xffffff81,%eax
140f: 7d 63 jge 1474 <filemap_unaccount_folio+0x8
4>
if (folio_test_hugetlb(folio))
1411: 80 7b 33 84 cmpb $0x84,0x33(%rbx)
1415: 74 4e je 1465 <filemap_unaccount_folio+0x75>
so we go from "mov, and, cmp, je" to just "cmpb, je", which must surely
be faster to execute as well as being more compact in the I$ (6 bytes vs 15).
Anyway, not tested but this is the patch I used to generate the above.
More for comment than application.
Right, it's likely very similar to my previous proposal to use 8 bit
(uint8_t) for the type.
https://lore.kernel.org/all/00ba1dff-7c05-46e8-b0d9-a78ac1cfc198@xxxxxxxxxx/
I would prefer if we would do that separately; unless someone is able to
raise why we care about zram + 256KiB that much right now. (claim: we don't)
iow, "this is ok for now", yes?
Perhaps. I'm not in position to claim that zram + 256KiB PAGE_SIZE is
irrelevant, but I'm also not in position to claim the opposite.
Matthew and David have ideas/proposals/patches to fix it should 256KiB
PAGE_SIZE become an issue.
Yes, let's keep it simple for now. There are various ways to handle that
if there is really the need to. 256KiB is not particularly common (quite
the opposite I would claim), and a simple fix would be dedicating 18
instead of 16 bit.
Long-term, we should handle it more cleanly though, and there are also
various ways forward (store offset in page, separate allocation like
memdesc for metadata, etc.).
Mess with turning page types from flags into values should be a separate
effort, because requires more care (e.g., PAGE_SLAB_MAPCOUNT_VALUE).
--
Cheers,
David / dhildenb
