[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <96e0915c-e836-4413-81ea-37bbb6abba6b@redhat.com>
Date: Wed, 26 Jun 2024 07:08:47 +0200
From: David Hildenbrand <david@...hat.com>
To: Sergey Senozhatsky <senozhatsky@...omium.org>,
Andrew Morton <akpm@...ux-foundation.org>
Cc: Matthew Wilcox <willy@...radead.org>, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, Mike Rapoport <rppt@...nel.org>,
Minchan Kim <minchan@...nel.org>, Hyeonggon Yoo <42.hyeyoo@...il.com>
Subject: Re: [PATCH v2 3/6] mm/zsmalloc: use a proper page type
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@...hat.com> 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@redhat.com/
>>>
>>> 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
Powered by blists - more mailing lists