[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <751358b2-aec2-43a3-cbbe-1f8c4469b6d3@suse.cz>
Date: Mon, 27 Sep 2021 21:07:21 +0200
From: Vlastimil Babka <vbabka@...e.cz>
To: Kent Overstreet <kent.overstreet@...il.com>,
Matthew Wilcox <willy@...radead.org>
Cc: linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, Johannes Weiner <hannes@...xchg.org>,
Linus Torvalds <torvalds@...ux-foundation.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 9/27/2021 8:09 PM, Kent Overstreet wrote:
> On Mon, Sep 27, 2021 at 07:05:26PM +0100, Matthew Wilcox wrote:
>> On Mon, Sep 27, 2021 at 07:48:15PM +0200, Vlastimil Babka wrote:
>>> Won't be easy to cram all that into two unsigned long's, or even a single
>>> one. We should avoid storing anything in the free page itself. Allocating
>>> some external structures to track free pages is going to have funny
>>> bootstrap problems. Probably a major redesign would be needed...
>>
>> Wait, why do we want to avoid using the memory that we're allocating?
>
> The issue is where to stick the state for free pages. If that doesn't fit in two
> ulongs, then we'd need a separate allocation, which means slab needs to be up
> and running before free pages are initialized.
So that's what I meant by the funny bootstrap problems - slab allocates pages
from the buddy allocator. And well, not just bootstrap, imagine free memory
becomes low, we need to reclaim pages, and in order to turn full pages to free
buddy pages we need to allocate these slab structures, and the slab is full too
and needs to allocate more backing pages...
By "major redesign" I meant e.g. something along - bitmaps of free pages per
each order? (instead of the free lists) Hm but I guess no, the worst case times
searching for free pages would just suck...
Powered by blists - more mailing lists