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 X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DEC21C433EF for ; Thu, 23 Sep 2021 22:12:45 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6D8C061260 for ; Thu, 23 Sep 2021 22:12:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 6D8C061260 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 00B8F900002; Thu, 23 Sep 2021 18:12:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EFCB26B0071; Thu, 23 Sep 2021 18:12:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DEB65900002; Thu, 23 Sep 2021 18:12:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0213.hostedemail.com [216.40.44.213]) by kanga.kvack.org (Postfix) with ESMTP id CFA516B006C for ; Thu, 23 Sep 2021 18:12:44 -0400 (EDT) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 77A3B18215F97 for ; Thu, 23 Sep 2021 22:12:44 +0000 (UTC) X-FDA: 78620238648.06.3F75ADB Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by imf07.hostedemail.com (Postfix) with ESMTP id 66FC610000A8 for ; Thu, 23 Sep 2021 22:12:43 +0000 (UTC) X-IronPort-AV: E=McAfee;i="6200,9189,10116"; a="211027339" X-IronPort-AV: E=Sophos;i="5.85,317,1624345200"; d="scan'208";a="211027339" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Sep 2021 15:12:41 -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) Authentication-Results: imf07.hostedemail.com; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=intel.com (policy=none); spf=none (imf07.hostedemail.com: domain of ira.weiny@intel.com has no SPF policy when checking 134.134.136.126) smtp.mailfrom=ira.weiny@intel.com X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 66FC610000A8 X-Stat-Signature: 8dabfijwtpgzaioier13bkscx1en1hzy X-HE-Tag: 1632435163-562242 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 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