[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20240625153338.8a4d049857d59e692a0d31e6@linux-foundation.org>
Date: Tue, 25 Jun 2024 15:33:38 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: David Hildenbrand <david@...hat.com>
Cc: Matthew Wilcox <willy@...radead.org>, Sergey Senozhatsky
<senozhatsky@...omium.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 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?
I'd like to push this into mm-"stable" later this week. Speak now or
forever hold your pieces.
Powered by blists - more mailing lists