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 2DE65C433FE for ; Wed, 9 Nov 2022 05:45:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5EDAD8E0001; Wed, 9 Nov 2022 00:45:40 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 59F006B0075; Wed, 9 Nov 2022 00:45:40 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4657A8E0001; Wed, 9 Nov 2022 00:45:40 -0500 (EST) 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 36F976B0073 for ; Wed, 9 Nov 2022 00:45:40 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id F3DCAC131D for ; Wed, 9 Nov 2022 05:45:39 +0000 (UTC) X-FDA: 80112816798.05.D7836CD Received: from mail-pg1-f174.google.com (mail-pg1-f174.google.com [209.85.215.174]) by imf21.hostedemail.com (Postfix) with ESMTP id A00121C0004 for ; Wed, 9 Nov 2022 05:45:34 +0000 (UTC) Received: by mail-pg1-f174.google.com with SMTP id f63so15329149pgc.2 for ; Tue, 08 Nov 2022 21:45:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=QcDDVezn7xjPbqkx+1Ddb+p68JUCfLKZfaOa0F02d2E=; b=WvbLsMoSazhptWNwl2dqoQ3THkUpJmCKHoG5uXH1hAtCGai/jPs06/KyWCA4iI+Hb1 AwqEDo7sxDydf2e4J6XN+wDchpcEiLaAt5RT+Rtx+i7jiD5c5+EV7wZzmn7I2fqgXMk1 Vnm1vz6oQEWcOyFUOIIjzK3/myef5SW7QtOot5vPGZDse8sUxB43VNZLC57KC/G9Ai3U 2dIMei7zixAOFX0b+wdkCIctq83nIM0ZhEn2JIxZJZkX9ciWlOb6eiB2GEKp7HPW9Fj8 EyZb/DDmXBfo0Qh3CtEgcIRLIlcC0DtdOD4pMcQeTka8cejTvYXgyIBi4sTM8dF7K2ia OorA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-transfer-encoding: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=QcDDVezn7xjPbqkx+1Ddb+p68JUCfLKZfaOa0F02d2E=; b=gBZ+azIjECiMIAUvwf8IYqVzvTTRH+1Ya1nsm05gxpjGQJ/wy5G/Jqp2VVHYPWxqzi sKn7t1qdsTY+ELTLW08oJijMX4J8B/fobqLt8zDrnBO9OGF4aA2+TYd1XIZ93JdV0iWN jXf1p84wPPyNZnxmStGhRsTZeFo1ULD6UOwkqJOLe6ggkZi3LXTmjUk61NMFsi6UVpMh 3b7tZwk0NCCKJ7DU2A7P1dGXeHMY1/9gbNCs+rvQO3mJgirxN4PTM+/ETD6NjxXRXYfD XQ+IjBVm5re2Z6JqObx5q+tKdO4SDR9VXa2Yburptggv6yBRFpcivb3SabZkcQcUfb7a nH3A== X-Gm-Message-State: ACrzQf3BGbXmFDU62OQt/rp+9hEkEI1hDEXeLYPXCLFNZruABJe8P4JB Up6FlJEMv6CSHF7bFy1Q5+c= X-Google-Smtp-Source: AMsMyM7UAC5K/2Nm3ERgLjmFiPNoIHwCZe7g4LDG1ofJKq9H12T3+KHxsJoFRmQC9HHNc54RBtYIRA== X-Received: by 2002:a05:6a00:993:b0:56c:80f6:db5 with SMTP id u19-20020a056a00099300b0056c80f60db5mr58894258pfg.45.1667972733389; Tue, 08 Nov 2022 21:45:33 -0800 (PST) Received: from hyeyoo ([114.29.91.56]) by smtp.gmail.com with ESMTPSA id 142-20020a621494000000b0056c6c63fda6sm7366065pfu.3.2022.11.08.21.45.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Nov 2022 21:45:32 -0800 (PST) Date: Wed, 9 Nov 2022 14:45:26 +0900 From: Hyeonggon Yoo <42.hyeyoo@gmail.com> To: HORIGUCHI =?utf-8?B?TkFPWUEo5aCA5Y+j44CA55u05LmfKQ==?= Cc: "linux-mm@kvack.org" , Andrew Morton , Christoph Lameter , Pekka Enberg , David Rientjes , Vlastimil Babka , Miaohe Lin , Matthew Wilcox , Minchan Kim , Mel Gorman , Andrea Arcangeli , Dan Williams , Hugh Dickins , Muchun Song , David Hildenbrand Subject: Re: [RFC v2 1/3] mm: move PG_slab flag to page_type Message-ID: References: <20221106140355.294845-1-42.hyeyoo@gmail.com> <20221106140355.294845-2-42.hyeyoo@gmail.com> <20221108053923.GA481964@hori.linux.bs1.fc.nec.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20221108053923.GA481964@hori.linux.bs1.fc.nec.co.jp> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1667972734; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=QcDDVezn7xjPbqkx+1Ddb+p68JUCfLKZfaOa0F02d2E=; b=x3t2FvE2mRp6LP2FEqz4QzsGlHyyg7ZW9eq2EADuzpo0O16IGUY73uUImJwPnmPHgJvr4T axb+4Qa7XwPndjNilCllXHvu/Yg4yprsBTOMRqrEioPylRI9BKpRiOcX/no56Zwq0DNUqm 61q2sBbdzvxVf6ciFcmuK35JKCxHS3A= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=WvbLsMoS; spf=pass (imf21.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.215.174 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1667972734; a=rsa-sha256; cv=none; b=bbM0BNsUnmM55LxTRl/cp9K/p/CHmaGBbgLbQ15IE6nMJIxLSr5k5wHHR2TLc9ND8WAnCv J0Dvdxyo44XusrrUcjVSeb2fwgqf9xovzjRiH5GqN9aj45Z9EiV+meQ84nNT/31HnyWAnB ONI/NRvcstF31RBU7oZSDlq0IxQ5A0w= X-Rspamd-Queue-Id: A00121C0004 Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=WvbLsMoS; spf=pass (imf21.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.215.174 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspamd-Server: rspam10 X-Rspam-User: X-Stat-Signature: j47dtx6asxmzuswm8a6qmx8e43yco71o X-HE-Tag: 1667972734-515045 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 Tue, Nov 08, 2022 at 05:39:24AM +0000, HORIGUCHI NAOYA(堀口 直也) wrote: > On Sun, Nov 06, 2022 at 11:03:53PM +0900, Hyeonggon Yoo wrote: > > For now, only SLAB uses _mapcount field as a number of active objects in > > a slab, and other slab allocators do not use it. As 16 bits are enough > > for that, use remaining 16 bits of _mapcount as page_type even when > > SLAB is used. And then move PG_slab flag to page_type. > > > > As suggested by Matthew, store number of active objects in negative > > form and use helper when accessing or modifying it. > > > > Note that page_type is always placed in upper 16 bits of _mapcount to > > avoid confusing normal _mapcount as page_type. As underflow (actually > > I mean, yeah, overflow) is not a concern anymore, use more lower bits. > > > > Add more folio helpers for PAGE_TYPE_OPS() not to break existing > > slab implementations. > > > > Remove PG_slab check from PAGE_FLAGS_CHECK_AT_FREE. buddy will still > > check if _mapcount is properly set at free. > > > > Exclude PG_slab from hwpoison and show_page_flags() for now. > > > > Note that with this patch, page_mapped() and folio_mapped() always return > > false for slab page. > > > ... > > > diff --git a/mm/memory-failure.c b/mm/memory-failure.c > > index 779a426d2cab..9494f47c4cee 100644 > > --- a/mm/memory-failure.c > > +++ b/mm/memory-failure.c > > @@ -1145,7 +1145,6 @@ static int me_huge_page(struct page_state *ps, struct page *p) > > #define mlock (1UL << PG_mlocked) > > #define lru (1UL << PG_lru) > > #define head (1UL << PG_head) > > -#define slab (1UL << PG_slab) > > #define reserved (1UL << PG_reserved) > > > > static struct page_state error_states[] = { > > @@ -1155,13 +1154,6 @@ static struct page_state error_states[] = { > > * PG_buddy pages only make a small fraction of all free pages. > > */ > > > > - /* > > - * Could in theory check if slab page is free or if we can drop > > - * currently unused objects without touching them. But just > > - * treat it as standard kernel for now. > > - */ > > - { slab, slab, MF_MSG_SLAB, me_kernel }, > > - > > Hi Hyeonggon, > Hi Naoya. > Actually the above part is dead code now and it's harmless to remove this. > identify_page_state() is never called when handling memory error event > on a slab page because HWPoisonHandlable() returns false for it. Oh wasn't aware of it. Thanks. That makes it easier. > If you remove it, a few other lines using MF_MSG_SLAB will be unneccessary, > so could you remove them too? Sure. Will split this to separate patch then. > As for testing, you can test this case for example like below: > > - install page-types (available in tools/vm/page-types.c), > - show the list of slab pages by "page-types -b slab -Nl" command > (the first column is PFNs) and choose one PFNs as target, > - call "page-types -a -X" (requires hwpoison-inject module to be loaded) > > In my testing server, dmesg shows like below: > > [598746.497805] Injecting memory failure at pfn 0x16295b > [598746.499208] Memory failure: 0x16295b: unhandlable page. > [598746.500570] Memory failure: 0x16295b: recovery action for unknown page: Ignored > > And your patchset seems not to affect this behavior. Cool! Will test it before sending next version. Thanks for looking at this :-) -- Thanks, Hyeonggon