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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id EE550C433FE for ; Fri, 7 Oct 2022 18:02:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 88FE26B0073; Fri, 7 Oct 2022 14:02:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 83EB66B0075; Fri, 7 Oct 2022 14:02:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6E1296B0078; Fri, 7 Oct 2022 14:02:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 5E5246B0073 for ; Fri, 7 Oct 2022 14:02:44 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id EABFF1A0A45 for ; Fri, 7 Oct 2022 18:02:43 +0000 (UTC) X-FDA: 79994923806.27.30CFD86 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf13.hostedemail.com (Postfix) with ESMTP id EC28D20022 for ; Fri, 7 Oct 2022 18:02:41 +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=S2z7kL/puGmrjNYlyHAwGHHEwyzprFts21kmJPvb+tA=; b=stIurYOm1Eq5Jmv9ryuWsRZALi S9nb4Z/bfXmUrPUhWv3StqLFqxF/QyVqlUSwbVnUgGsXD2ZGX1OsvDVKzmz7hpk6LP/lL4a4Nw6Tn AIfqou5bRhZewiYU53EvuEoitfLf6mkhGoko08mdshH6vAuDA+NB0qvE3DougXZr+17YHTnJihD6b sF5DVL8WnOEa+EJVEHOn4K/TVAwt/fj/qsnE/kBMKN2NNVXKxkcU7lLycd54yNweptmfGj9Zkuk/R ZW6cKdNVO2kDtbtH9XofNXSzKGvoMu2fwnsC4unM8lfIs5cD6YntnoCQkYEBeNW8pJ8WCguiBgaiz 07l0XqFQ==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1ogrgB-0024GK-TE; Fri, 07 Oct 2022 18:02:35 +0000 Date: Fri, 7 Oct 2022 19:02:35 +0100 From: Matthew Wilcox To: Hyeonggon Yoo <42.hyeyoo@gmail.com> Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Vlastimil Babka , Roman Gushchin , Naoya Horiguchi , Miaohe Lin , Minchan Kim , Mel Gorman , Andrea Arcangeli , Dan Williams , Hugh Dickins , Muchun Song , David Hildenbrand , Andrey Konovalov , Marco Elver Subject: Re: [PATCH] mm: move PG_slab flag to page_type Message-ID: References: <20220919125708.276864-1-42.hyeyoo@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1665165762; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=S2z7kL/puGmrjNYlyHAwGHHEwyzprFts21kmJPvb+tA=; b=6bxPl+U1T+waitLU2aaNSiYOUB/Drsmom5jxiXW4O/vmMELV4dygjeMh/dXUnllW+CRoOc NvHqU9vu2QODzglhJVX20gVxC25qvulTLvEhoA4J47XHb1upvDOg9FmxX7EpFp+x8rCVZY 2CduDcexI4mIme79gFD2XOc8bUVZOv4= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=stIurYOm; spf=none (imf13.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1665165762; a=rsa-sha256; cv=none; b=fZ/tKbp1M4QphWIhN3BwqcuK2qm4lrlmkPypZHYXU0XeJv0T6h8yxTTwdnhYQ7AxPlXCRd cIb9Z685QIUO+sonqPtOaQCw8/xR6xvepgpqP0Wsb6JyU7sXxc7hkv7FikUt3iNKccJdN3 QJ8VcBWjx/G9W/7IQ/b2oGsaILbbmHs= Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=stIurYOm; spf=none (imf13.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-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: d99fdb4fygmazaiqf9juohjud9mry5sq X-Rspamd-Queue-Id: EC28D20022 X-HE-Tag: 1665165761-113123 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 Fri, Oct 07, 2022 at 10:36:56PM +0900, Hyeonggon Yoo wrote: > > First, you say that folio_mapped() returns false for slab pages. That's > > only true for order-0 slab pages. For larger pages, > > > > if (!folio_test_large(folio)) > > return atomic_read(&folio->_mapcount) >= 0; > > if (atomic_read(folio_mapcount_ptr(folio)) >= 0) > > return true; > > > > so that's going to depend what folio_mapcount_ptr() aliases with. > > IIUC it's true for order > 0 slab too. > > As slab pages are not mapped to userspace at all, > entire compound page nor base pages are not mapped to userspace. > > AFAIK followings are true for order > 0 slab: > - (first tail page)->compound_mapcount is -1 That's the part I wasn't sure of. I think we do, in prep_compound_head(). > - _mapcount of base pages are -1 > > So: > folio_mapped() and page_mapped() (if applied to head page) > returns false for larger pages with this patch. > > I wrote simple testcase and did check that folio_mapped() and page_mapped() > returns false for both order-0 page and larger pages. (and SLAB > returned true for them before) > > > Second, this patch changes the behaviour of PageSlab() when applied to > > tail pages. > > Altough it changes the way it checks the flag, > > it does not change behavior when applied to tail pages - PageSlab() on tail > page returns false with or without this patch. Really? It seems to me that it returns true at the moment. Look: __PAGEFLAG(Slab, slab, PF_NO_TAIL) #define PF_NO_TAIL(page, enforce) ({ \ VM_BUG_ON_PGFLAGS(enforce && PageTail(page), page); \ PF_POISONED_CHECK(compound_head(page)); }) so AFAICS, PageSlab checks the Slab bit on the head page, not the tail page. > If PageSlab() need to return true for tail pages too, > we may make it check page_type at head page. > > But I'm not sure when it the behavior is needed. > Can you please share your insight on this? There are tools like tools/vm/page-types.c which expect PageSlab to return true for tail pages. > > Which raises the further question of what PageBuddy(), > > PageTable(), PageGuard() and PageIsolated() should do for multi-page > > folios, if that is even possible. > > For users that uses real compound page like slab, we can make it check > page_type of head page. (if needed) > > But for cases David described, there isn't much thing we can do > except making them to use real compound pages. > > > Third, can we do this without that awkward __u16 thing? Perhaps > > > > -#define PG_buddy 0x00000080 > > -#define PG_offline 0x00000100 > > -#define PG_table 0x00000200 > > -#define PG_guard 0x00000400 > > +#define PG_buddy 0x00010000 > > +#define PG_offline 0x00020000 > > +#define PG_table 0x00040000 > > +#define PG_guard 0x00080000 > > +#define PG_slab 0x00100000 > > > > ... and then use wrappers in slab.c to access the bottom 16 bits? > > Definitely! I prefer that way and will adjust in RFC v2. > > Thank you for precious feedback. No problem. I suggested (in an off-list email) that you consider counting 'active' by subtraction rather than addition because I have a feeling that int active(struct slab *slab) { return ~(slab->page_type | PG_slab); } would be better than int active(struct slab *slab) { return slab->page_type & 0xffff; } at least in part because you don't have to clear the bottom 16 bits of page_type when you clear PG_slab, and you don't have to re-set them when you set PG_slab.