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 6D682C433F5 for ; Sat, 8 Oct 2022 04:21:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A43216B0072; Sat, 8 Oct 2022 00:21:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9F2706B0073; Sat, 8 Oct 2022 00:21:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8927D6B0074; Sat, 8 Oct 2022 00:21:36 -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 731CC6B0072 for ; Sat, 8 Oct 2022 00:21:36 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 436B0160B15 for ; Sat, 8 Oct 2022 04:21:36 +0000 (UTC) X-FDA: 79996483392.03.CE8D9A0 Received: from mail-pf1-f172.google.com (mail-pf1-f172.google.com [209.85.210.172]) by imf19.hostedemail.com (Postfix) with ESMTP id EC57B1A001A for ; Sat, 8 Oct 2022 04:21:35 +0000 (UTC) Received: by mail-pf1-f172.google.com with SMTP id 204so6484780pfx.10 for ; Fri, 07 Oct 2022 21:21:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=rsvYzD8csLN9IeUNf2gCwuuY/70zke74chneBqizKgo=; b=lp4jNDBitdbT9aePSHmYfAaSqV3KlCf7y2QCVnKCc3jJerXBN5vwCB4ybkFwT8xVNF 195yOEGEjaBCegUejYUOprOMEC3Nz6NoD8FrLgVQuWyuKruzZs70Yvgx+Fo0Jlx8HwsS zXH/mZigE04VRmcW27jGTz2zyYaDWtrjZj2Lfaa/Z7xUGK4iGV69Mom/oqywJAPCb/HE tr7KHt0Wzq8EXqBBp47oaksmPJoJgcPVSl0vzmeRyBhloD6clHwSAlM9/UgXMsRPit2V nRwoh8Kk7rIt5u02TgIeNmF14jfANYioXcOur/RMC9WjWl7bEa/03YBabDQyxiRYdChl 4+JA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=rsvYzD8csLN9IeUNf2gCwuuY/70zke74chneBqizKgo=; b=biXVgy9Pt5tUqVph5Wv43GZQxaJINeJ8CVoSYM5ZTTxxcm51RzXqkg0+s0K5zpMSUr SDkkvVyJ2bt0/ywKSItHU9/C5Vh6RzLNMsCVUsp/I0mjWAMjAP8OQW6g3yudiXVjJuf3 NGBtPMiR9vFtwINH6ZP37962w7bOubVw3QF1Id0RzKJnBiKBeDESYJ63SuovgxNfWtbX H46of0xRdP93bSv4aNLnA1LaNMU/e1Vy+KCaM7eChmeTxIgOOsMD9O2IlGLTvGackm31 oPbO/OyYDsHOI8EkpSdyD5zJDHHwSUPAlkBEUEnf7A1GgzIM9HUk1rUJyRZfK3PPo4TU BjZw== X-Gm-Message-State: ACrzQf13svHzchzw4UbYZplIF7qMsSjpuRhKuyDNwhiPqlRDH6+0n96o LoYLUzfM9ov8MK9yGOELVYI= X-Google-Smtp-Source: AMsMyM792XUEFcT/zqSQkc6cMxM+d6PeGOQAzMh/85CMbv96hC9zRkzrqumLaO7VTDZsVvb8oiep2Q== X-Received: by 2002:a65:6e9a:0:b0:44c:2476:12e0 with SMTP id bm26-20020a656e9a000000b0044c247612e0mr7583515pgb.159.1665202894812; Fri, 07 Oct 2022 21:21:34 -0700 (PDT) Received: from hyeyoo ([114.29.91.56]) by smtp.gmail.com with ESMTPSA id b24-20020aa79518000000b00560bb4a57f7sm2533696pfp.179.2022.10.07.21.21.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 07 Oct 2022 21:21:33 -0700 (PDT) Date: Sat, 8 Oct 2022 13:21:26 +0900 From: Hyeonggon Yoo <42.hyeyoo@gmail.com> To: Matthew Wilcox 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-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1665202896; a=rsa-sha256; cv=none; b=fbNDmfxK34hqyzRXHhKJfSEMP75lHwtws8kc9WXakmyOa222nhEaBQZp4l+8XabQpO2ZnZ CzRWsVrqwohju3GY2zX+hqtdeyKRNSKkxUMeqQMXa4nLxmdYHqrkYxPUQzXLNIVCJ45fQm ljbaaPxoR0gFv1QSjF6DXLlX6TMOmbU= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=lp4jNDBi; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf19.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.210.172 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1665202896; 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=rsvYzD8csLN9IeUNf2gCwuuY/70zke74chneBqizKgo=; b=V9OcRGhNGrdO2bOaMFoCamQoe77YLsa5wtHrgMqJq9ChhIwQt9WyvVhb9OLBbqWgox0ChO lMI3yPNZ/aOkb4YHyGQvgHP/Cf8I7xr3ko2jQrsNLj/fws6SuRTHthc3ceAGKWWicMpPAb cXOlcuMEBg5YVAdKb/O3rfCUP9bDvrw= X-Rspam-User: X-Stat-Signature: f4dx8or8bjusydjkrphghy5yyq4184eg X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: EC57B1A001A Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=lp4jNDBi; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf19.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.210.172 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com X-HE-Tag: 1665202895-348900 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 07:02:35PM +0100, Matthew Wilcox wrote: > 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(). Right, exactly! > > > - _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) FYI, This is still true even after fixing my mistaken test case (see below) > > > > > 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. You are right. I misunderstood it due to my mistakenly written test case (without passing __GFP_COMP... how silly of me :D) Hmm okay, then I will implement PF_NO_TAIL policy that works on page_type. > > > 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. Yeah, I was wondering what is the benefit of the that approach. After implementing both approach, your suggestion seems better to me too. Many thanks, Matthew! -- Hyeonggon