Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp987411pxb; Thu, 23 Sep 2021 15:16:45 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw9ohrC4o5OGdSXrDQ42gV0kwrl4Czht9Z3ZyN4+kt40XJVUsECy+cFxDmUaLMBLsp6WLtN X-Received: by 2002:a17:906:2a44:: with SMTP id k4mr7987462eje.328.1632435404810; Thu, 23 Sep 2021 15:16:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632435404; cv=none; d=google.com; s=arc-20160816; b=lMJtgJbimXOKdeT4cn6s9DRbEx1EN411bvWxRA1mLp529MPo0slPmU7sEZtOh8ibEL XRZwixtmOUuO3Vujg9lntNoZ9foj7xexJdr6GlBTpBbvU7hlDFjs7ypPV1BBQhnKNk8w 4TOPkwXKXBPFEGqXAs+N2rEmKfW16pgC+/q7/bX08knjWSuSoWn/xLvlBxqw2LnZ5tYM uUeN71kZW21B/PrRUl8dKxfew0wDvmyXt0BFboEBqhzO3+FFrZVRgU0FylO3C9ioGQJT Qx19vHCB4SzN9o9ZAWT2Cz070NrizWzbREF0+lbTw7V/PKDnFG2nd++jqftqSH6tXOnZ 8B9w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=9Dhpi79mONFXgheriSDE9pmrRQ5IgGYeHlpLZm+n2g8=; b=ZLl1PSGWAy0JWhCgdr5xvcyBDcM7OZl0KOV/w2DMtSuvjQ69+68y4wR8oT647lnQHW G+nV3oFghVS1gQX88BLBik5oaAgw/vUvWSVMUYRv4ksk8tlPksaD4bmupkEk0G3rcGRK KKtkYKSn2MMJFeM/ApPgGWpZaPeQVnI4PXQbndETsODc+S0kbb1AsBNa1+Yz6dEnsx+J DN4sxxH03vY9bl/iAl+d6bULieMuuROEYQs6hQXjOuS0Eqw8xsBVEU805+GSjWgE5Tph TjffGgTtPj3wrrYYHRBEhhFd1qd6NFafMuyIIZ5NgYw+0umFoV3dvYvAex8Uiy1NwI7i y4JQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m15si7441313edp.413.2021.09.23.15.16.20; Thu, 23 Sep 2021 15:16:44 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243423AbhIWWOQ (ORCPT + 99 others); Thu, 23 Sep 2021 18:14:16 -0400 Received: from mga14.intel.com ([192.55.52.115]:44436 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243412AbhIWWOO (ORCPT ); Thu, 23 Sep 2021 18:14:14 -0400 X-IronPort-AV: E=McAfee;i="6200,9189,10116"; a="223597605" X-IronPort-AV: E=Sophos;i="5.85,317,1624345200"; d="scan'208";a="223597605" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Sep 2021 15:12:42 -0700 X-IronPort-AV: E=Sophos;i="5.85,317,1624345200"; d="scan'208";a="514282857" Received: from iweiny-desk2.sc.intel.com (HELO localhost) ([10.3.52.147]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Sep 2021 15:12:41 -0700 Date: Thu, 23 Sep 2021 15:12:41 -0700 From: Ira Weiny To: Matthew Wilcox Cc: Kent Overstreet , Johannes Weiner , Linus Torvalds , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Andrew Morton , "Darrick J. Wong" , Christoph Hellwig , David Howells Subject: Re: Folio discussion recap Message-ID: <20210923221241.GG3053272@iweiny-DESK2.sc.intel.com> References: <20210923004515.GD3053272@iweiny-DESK2.sc.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.1 (2018-12-01) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 23, 2021 at 04:41:04AM +0100, Matthew Wilcox wrote: > On Wed, Sep 22, 2021 at 05:45:15PM -0700, Ira Weiny wrote: > > On Tue, Sep 21, 2021 at 11:18:52PM +0100, Matthew Wilcox wrote: > > > +/** > > > + * page_slab - Converts from page to slab. > > > + * @p: The page. > > > + * > > > + * This function cannot be called on a NULL pointer. It can be called > > > + * on a non-slab page; the caller should check is_slab() to be sure > > > + * that the slab really is a slab. > > > + * > > > + * Return: The slab which contains this page. > > > + */ > > > +#define page_slab(p) (_Generic((p), \ > > > + const struct page *: (const struct slab *)_compound_head(p), \ > > > + struct page *: (struct slab *)_compound_head(p))) > > > + > > > +static inline bool is_slab(struct slab *slab) > > > +{ > > > + return test_bit(PG_slab, &slab->flags); > > > +} > > > + > > > > I'm sorry, I don't have a dog in this fight and conceptually I think folios are > > a good idea... > > > > But for this work, having a call which returns if a 'struct slab' really is a > > 'struct slab' seems odd and well, IMHO, wrong. Why can't page_slab() return > > NULL if there is no slab containing that page? > > No, this is a good question. > > The way slub works right now is that if you ask for a "large" allocation, > it does: > > flags |= __GFP_COMP; > page = alloc_pages_node(node, flags, order); > > and returns page_address(page) (eventually; the code is more complex) > So when you call kfree(), it uses the PageSlab flag to determine if the > allocation was "large" or not: > > page = virt_to_head_page(x); > if (unlikely(!PageSlab(page))) { > free_nonslab_page(page, object); > return; > } > slab_free(page->slab_cache, page, object, NULL, 1, _RET_IP_); > > Now, you could say that this is a bad way to handle things, and every > allocation from slab should have PageSlab set, Yea basically. So what makes 'struct slab' different from 'struct page' in an order 0 allocation? Am I correct in deducing that PG_slab is not set in that case? > and it should use one of > the many other bits in page->flags to indicate whether it's a large > allocation or not. Isn't the fact that it is a compound page enough to know that? > I may have feelings in that direction myself. > But I don't think I should be changing that in this patch. > > Maybe calling this function is_slab() is the confusing thing. > Perhaps it should be called SlabIsLargeAllocation(). Not sure. Well that makes a lot more sense to me from an API standpoint but checking PG_slab is still likely to raise some eyebrows. Regardless I like the fact that the community is at least attempting to fix stuff like this. Because adding types like this make it easier for people like me to understand what is going on. Ira