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 816D7C433EF for ; Mon, 27 Sep 2021 18:10:06 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3114260F12 for ; Mon, 27 Sep 2021 18:10:06 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 3114260F12 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id BA2546B006C; Mon, 27 Sep 2021 14:10:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B53396B0071; Mon, 27 Sep 2021 14:10:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A1A8E6B0072; Mon, 27 Sep 2021 14:10:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0092.hostedemail.com [216.40.44.92]) by kanga.kvack.org (Postfix) with ESMTP id 94AFE6B006C for ; Mon, 27 Sep 2021 14:10:05 -0400 (EDT) Received: from smtpin32.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 468DF8249980 for ; Mon, 27 Sep 2021 18:10:05 +0000 (UTC) X-FDA: 78634142370.32.7C2BF0C Received: from mail-qk1-f178.google.com (mail-qk1-f178.google.com [209.85.222.178]) by imf19.hostedemail.com (Postfix) with ESMTP id EBB19B0000AC for ; Mon, 27 Sep 2021 18:10:04 +0000 (UTC) Received: by mail-qk1-f178.google.com with SMTP id b65so37415781qkc.13 for ; Mon, 27 Sep 2021 11:10:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=+74FrA4BDR4sTJKoxyTfHdDlbMZ+846PN+NihhHFxi0=; b=ehqZSv84Rwon47h2I0MSn10EHh/0KJhBFRXdP4VtV752eOgbQ79oPe6vtf+VQJoWle +ydDV4ul489wNqir+HG4YHEMIRjJI/UVe5SZFbITA+FlrtEmsw4zVN8mhplSw5cYa2A2 ct6+4/ODfOmLqJivvh5cBSns8xn++DGyOjgvA0+W6mrsbTdNAgxLZ1MDlvlQgmZ1R+Bc m08dNZcbay20EVIB1D8zCPTspjhjs3Wyk7n1wZK8lHRiCQAXdlGn28mSuBTkdDqHMel6 6aVhG7lI8MpaEgL6ILOphjfwAWmkNIfSOeod3dLX2MkRQOsaKLaiyFP2O1DRpnt2+azN 7skA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=+74FrA4BDR4sTJKoxyTfHdDlbMZ+846PN+NihhHFxi0=; b=OpCk7NkuvqO8WbF2USQORSaO+JMi563TegcQMl9IR9h8+eZWlHSzySIrmU5vqN7Gy0 mqnq5v9LE0qzhphtJIKDpkAm/Q1jSjoTfY6zwT/KZA32XMqZX8E4v4qMWdZE7LDb/mlZ biBYk3vHsxSQUvLNDT+NhkHwpSl70HhkhkXFe+BALT1sm38dfFmtdKzBCOVeAsNUacv7 g9FRVpeJTOk6vVbPNT5cWoSvdPrU8Hic/NY9TNXUfGzRVPR6yhC9kDmOcJXPYjhx2XY/ nG6bt28WgTzg0qixDWtvwYeW27grVk0338a12YgwR4uFqtF2q5fVExS0kkh69hsYn56R 384A== X-Gm-Message-State: AOAM5314FBic5dpgQE44Ezn+JS0Ek7pA2Ua6IihQOubvK+jF3daSDcI5 nmzRfuEZHloFhMyQkXJxYAbiQuJq+AOK X-Google-Smtp-Source: ABdhPJwx4bWT5tiU3pyWgUXRe+OIrjlTHS1HE/IWluKnSpeJEqJ0TWg/NzCTSWGffa5gaQFvucXuIQ== X-Received: by 2002:a37:4593:: with SMTP id s141mr1302331qka.368.1632766192215; Mon, 27 Sep 2021 11:09:52 -0700 (PDT) Received: from moria.home.lan (c-73-219-103-14.hsd1.vt.comcast.net. [73.219.103.14]) by smtp.gmail.com with ESMTPSA id o21sm11266790qtt.12.2021.09.27.11.09.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 27 Sep 2021 11:09:51 -0700 (PDT) Date: Mon, 27 Sep 2021 14:09:49 -0400 From: Kent Overstreet To: Matthew Wilcox 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: EBB19B0000AC X-Stat-Signature: xo7unf9anb3pjxuky6xhs8cmzgmcp9xj Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=ehqZSv84; spf=pass (imf19.hostedemail.com: domain of kent.overstreet@gmail.com designates 209.85.222.178 as permitted sender) smtp.mailfrom=kent.overstreet@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspamd-Server: rspam06 X-HE-Tag: 1632766204-419070 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 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.