From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4FE51C433FE for ; Tue, 28 Sep 2021 03:20:24 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D23FA611C3 for ; Tue, 28 Sep 2021 03:20:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org D23FA611C3 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 56DA8900003; Mon, 27 Sep 2021 23:20:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4F6B5900002; Mon, 27 Sep 2021 23:20:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3E5A0900003; Mon, 27 Sep 2021 23:20:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0158.hostedemail.com [216.40.44.158]) by kanga.kvack.org (Postfix) with ESMTP id 29046900002 for ; Mon, 27 Sep 2021 23:20:23 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id C08B12D4A9 for ; Tue, 28 Sep 2021 03:20:22 +0000 (UTC) X-FDA: 78635529084.27.C6AA501 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf07.hostedemail.com (Postfix) with ESMTP id 0497F10000AC for ; Tue, 28 Sep 2021 03:20:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=sBFbi/If9ujFQsh6+OOsbzjxSKlHFm7peAgHiM3zc7w=; b=kaVUFoCmBwAtZgeh69BoiqQo3O PCwSDMDW8d3nJRX6Obf3ZQWznzLKHuHuC3yMQMQb2AnmPfhHuIONoS3ELCJWHYd8PiFVg3Q3xqh6e ew3mdA9lp3PqkT/mXOAlZmV4H7mYdcLU8POaRiBXZ2dViZRGJTCtUkwDk1dcS4QrapzgMopn8m6nd 49lMpilWetA4XJDSy5XwZpXm7by457RLwurUAZBp2kPlzVJgQ0t4Geq9Kt3hf106/oHLV4EujDquv pKUtpPLdJ+1FVP3634WN/btfQIYRxmBw/DWsVNVKN7FaCSRmmG7SUDGMz1DtGvibAGfJPvpXL64UP StZf9C6g==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1mV3eH-00ARfz-Fb; Tue, 28 Sep 2021 03:19:26 +0000 Date: Tue, 28 Sep 2021 04:19:17 +0100 From: Matthew Wilcox To: Kent Overstreet Cc: Vlastimil Babka , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Johannes Weiner , Linus Torvalds , Andrew Morton , "Darrick J. Wong" , Christoph Hellwig , David Howells Subject: Re: Struct page proposal Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 0497F10000AC X-Stat-Signature: j5kyprk8z5h8rqxsmrcqf3h73pwaub9c Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=kaVUFoCm; spf=none (imf07.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none X-Rspamd-Server: rspam06 X-HE-Tag: 1632799221-186994 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, Sep 27, 2021 at 02:16:53PM -0400, Kent Overstreet wrote: > On Mon, Sep 27, 2021 at 07:12:19PM +0100, Matthew Wilcox wrote: > > On Mon, Sep 27, 2021 at 02:09:49PM -0400, 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: > > > > > On 9/23/21 03:21, Kent Overstreet wrote: > > > > > > So if we have this: > > > > > > > > > > > > struct page { > > > > > > unsigned long allocator; > > > > > > unsigned long allocatee; > > > > > > }; > > > > > > > > > > > > The allocator field would be used for either a pointer to slab/slub's state, if > > > > > > it's a slab page, or if it's a buddy allocator page it'd encode the order of the > > > > > > allocation - like compound order today, and probably whether or not the > > > > > > (compound group of) pages is free. > > > > > > > > > > The "free page in buddy allocator" case will be interesting to implement. > > > > > What the buddy allocator uses today is: > > > > > > > > > > - PageBuddy - determine if page is free; a page_type (part of mapcount > > > > > field) today, could be a bit in "allocator" field that would have to be 0 in > > > > > all other "page is allocated" contexts. > > > > > - nid/zid - to prevent merging accross node/zone boundaries, now part of > > > > > page flags > > > > > - buddy order > > > > > - a list_head (reusing the "lru") to hold the struct page on the appropriate > > > > > free list, which has to be double-linked so page can be taken from the > > > > > middle of the list instantly > > > > > > > > > > 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. > > > > But the thing we're allocating is at least PAGE_SIZE bytes in size. > > Why is "We should avoid storing anything in the free page itself" true? > > Good point! > > Highmem and dax do complicate things though - would they make it too much of a > hassle? You want to get rid of struct page for dax (what's the right term for > that kind of memory?), but we're not there yet, right? DAX is used for persistent memory, often abbreviated to pmem. "Getting there" involves rooting out struct page from all kinds of data structures. sg lists are the obvious place to start so that we can do I/O to memory that's not backed by a struct page. Get that working and the rent-a-VM companies will love you. Right now, we either pay the 1.6% tax twice (once for the struct pages in the host, and once in the guest), or we have horrendous hacks to create struct pages on the fly so the host can do I/O to the guest's memory.