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 B7F7DC433F5 for ; Mon, 27 Sep 2021 18:16:59 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4F6A260F11 for ; Mon, 27 Sep 2021 18:16:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 4F6A260F11 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 DE39A6B0071; Mon, 27 Sep 2021 14:16:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D93016B0072; Mon, 27 Sep 2021 14:16:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C5CD06B0073; Mon, 27 Sep 2021 14:16:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0132.hostedemail.com [216.40.44.132]) by kanga.kvack.org (Postfix) with ESMTP id B87C16B0071 for ; Mon, 27 Sep 2021 14:16:58 -0400 (EDT) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 7BE6432615 for ; Mon, 27 Sep 2021 18:16:58 +0000 (UTC) X-FDA: 78634159716.22.75756A8 Received: from mail-qv1-f43.google.com (mail-qv1-f43.google.com [209.85.219.43]) by imf09.hostedemail.com (Postfix) with ESMTP id 3C01A3000111 for ; Mon, 27 Sep 2021 18:16:58 +0000 (UTC) Received: by mail-qv1-f43.google.com with SMTP id n6so3504736qvp.7 for ; Mon, 27 Sep 2021 11:16:58 -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=ktSTORNNq8S1FcURLzITo6BxzVuTeC9E0wfbs37JzGc=; b=IT1kjY/if5cD1zKyRa9VUjaXJt1swUgBNyRGFvHbY+Fq4bG85GPx4BaEtxUVVeqcgA Z6xG1wzGSwjXoTdi8mzfQ2uHaI6iEJgl2fM+fdYS6B00f6xuSxrUj8e+am6pHvNYjsg0 K5PJ8ezDoztXKy5wNvLwqBMS/exbl9kVlRAeNtyIBeCMBG/+TFXH+23QWSwGwVB7ZT++ SLOFFd35BptSD8SR1pv3WM+Hyyc6hL19Ltg7KEP0tH2oKCNlABNEtwUXkrUqzT5CI80A umc+oWVeyhAhcCqDpvm/BFeblbMAgwlAq97wXwtNbTrEjCLIKVcX2107DzjzATYZg+23 b6Zw== 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=ktSTORNNq8S1FcURLzITo6BxzVuTeC9E0wfbs37JzGc=; b=hzS1YyxiorZxMwCXtjdQIb9dKw1hSPIy8Vtt04+brFNjr8uoXWX9s8DwZ0PPTL8kqI 1l6GVj0YGJms4UUFvZsenijNjqxxcJGDkdjP6Ez4650LpFreYodsXQlU54Q0y4aFtGDU GsfJwBNoY0x6oFR1tA9tMW40ZgkPNaDsz8TLPnlH1qmWMaA9hfmBrTUbO+mDZuWj+7eh jl+2aDos9cFikOumHlmnKJoI7YsTXydiN9q7JzrUBtbvFsITYQGFKnBIhNQ8j94QNeRI 5gmPL0vq8qKiMHa2grIIm4ZJAFoS9CznxLi0gxZWAGADIyRDJtxod7STTPsfMnPQkh0i qSpw== X-Gm-Message-State: AOAM532jfOdCsM2nROnPMBaWEodOKWzcRCHQl4qtW1humz4uw2SBW+hM AtlmPtcZJqSgYoA43En0gA== X-Google-Smtp-Source: ABdhPJwzHqe1Z/6WYpHdZTlByURoz+WpRNXlH8q4EUdr7WookqRdsvv9RU2H2t630rE/aczNPs2anQ== X-Received: by 2002:a05:6214:56e:: with SMTP id cj14mr162544qvb.10.1632766617610; Mon, 27 Sep 2021 11:16:57 -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 m24sm12875570qki.40.2021.09.27.11.16.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 27 Sep 2021 11:16:55 -0700 (PDT) Date: Mon, 27 Sep 2021 14:16:53 -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: Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="IT1kjY/i"; spf=pass (imf09.hostedemail.com: domain of kent.overstreet@gmail.com designates 209.85.219.43 as permitted sender) smtp.mailfrom=kent.overstreet@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 3C01A3000111 X-Stat-Signature: p1845cn59a5ewumnwtkoxhghieg61ey9 X-HE-Tag: 1632766618-524030 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: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? Very curious why we need to be able to pull pages off the middle of a freelist. If we can make do with singly linked freelists, then I think two ulongs would be sufficient.