[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=whQE3eZdFgtoeRmXVsO93c-nSbdheTvtUJcztJaE_KKEw@mail.gmail.com>
Date: Mon, 27 Sep 2021 12:04:57 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Vlastimil Babka <vbabka@...e.cz>
Cc: David Hildenbrand <david@...hat.com>,
Matthew Wilcox <willy@...radead.org>,
Kent Overstreet <kent.overstreet@...il.com>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux-MM <linux-mm@...ck.org>,
Johannes Weiner <hannes@...xchg.org>,
Andrew Morton <akpm@...ux-foundation.org>,
"Darrick J. Wong" <djwong@...nel.org>,
Christoph Hellwig <hch@...radead.org>,
David Howells <dhowells@...hat.com>
Subject: Re: Struct page proposal
On Mon, Sep 27, 2021 at 11:53 AM Vlastimil Babka <vbabka@...e.cz> wrote:
>
> I was thinking of debug_pagealloc (unmaps free pages from direct map) but yeah,
> the list is longer.
In fact, the _original_ free page list was in the page itself, not in
'struct page'.
The original reason to move it into 'struct page' ended up being
performance, iirc.
Because of how now the free page list was always in the same cache
line set, the page allocator caused horrendous cache patterns on
direct-mapped caches.
Direct-mapped caches may thankfully be gone, and we have a lot of
other things that end up having that property of "same offset within a
page" just because of allocation patterns (task struct allocations
being but one example), but it might still be something to try to
avoid.
Linus
Powered by blists - more mailing lists