Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp438362pxb; Mon, 25 Oct 2021 11:11:43 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxZTb9dLg527UKxOAwCsAiVIkFa+T2cUj+N51GrW5r8pklIT8AmgyX5ptpPjmKOryp8u8D4 X-Received: by 2002:a17:907:3d89:: with SMTP id he9mr25506889ejc.96.1635185502762; Mon, 25 Oct 2021 11:11:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1635185502; cv=none; d=google.com; s=arc-20160816; b=oPaQVu4JpSPgCt3N9EUXddhsRZqnFs4hwiRsh/AemipfSKA8oHWRlpIbfYwdt6wl37 1k0WY+MHtFfjVygMtcps59m74J95HBG9KBIps1sI/BrxtxlQmpRgT01LuIFB3rPn0sXc 3KB3qnqyZfrSq+Rfgz1v0ywMpR7cVQgR2EI5ys+vnrEUbedQymG0Z1zhJ1CpHMUagF+g Q2nGY2JIsIrB+UQo80vpeGKNdG9QKbp1GHO3VqDY1XAnJqCTv/wuWzE2WQhzHpdjq9k+ Ld3WCpzkkFAV6hKDkzSJf2N4favu2jtsj2AOSPG6TDRMGVsejIvErDqVQf5pTKEuC85O ftUA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:subject :from:references:cc:to:content-language:user-agent:mime-version:date :message-id:dkim-signature:dkim-signature; bh=v+x+7fcw/+YytMUhFAnt+FKGGNMBk+QUr2gwfDdTJ7Q=; b=IugkMWFp8nNcHuuvK6stcks+HvEZ0aLAQDvl64mnav9wukWFO49zjYcADJebIcs/KX acUoS9hzjCddZVVhsQFz4QATqpLKRjtbflbPf+8oA2i/o/pBp/nI+Q0gf+TzxoYxiM/p 7UncImuqEeBBYqtz8bCbc35ZLrKqDlgH8pjgY7wn5AnIBXlNmIfIJoZlKCnkkTRnwxXA g1Uonic29kLHCCoUJ2wSBrvoDwxzZrU6ObNvesw07TxLlbLlTPnFNjhPdzoHiZaU2PBm 2BDfl6NCUKTmLODQAWh+U0/D6QM6x4pCb6lBcGXsqwRDs1CNdgXchA0FULMjJKFO+t3H 8JvQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=LndAzJXJ; dkim=neutral (no key) header.i=@suse.cz; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id hp6si1518734ejc.765.2021.10.25.11.11.18; Mon, 25 Oct 2021 11:11:42 -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; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=LndAzJXJ; dkim=neutral (no key) header.i=@suse.cz; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232478AbhJYNve (ORCPT + 99 others); Mon, 25 Oct 2021 09:51:34 -0400 Received: from smtp-out2.suse.de ([195.135.220.29]:39340 "EHLO smtp-out2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231586AbhJYNvb (ORCPT ); Mon, 25 Oct 2021 09:51:31 -0400 Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 384531FD3A; Mon, 25 Oct 2021 13:49:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1635169748; h=from:from:reply-to: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; bh=v+x+7fcw/+YytMUhFAnt+FKGGNMBk+QUr2gwfDdTJ7Q=; b=LndAzJXJfTth62Dc+rcWv8dmONm65/jechL4fZsahPBHLAwFzaZdaJWkpCH7WJElLxEo/L GYbfYDbLPOZxtr/iCEh7gEhPEwk5ICwQX4P5O3JB2CMT2va8qF+Gm35uzG4v18ygiD72Pd TfC75gYaM0AsE7YSsKPmBVpYunXWtTo= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1635169748; h=from:from:reply-to: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; bh=v+x+7fcw/+YytMUhFAnt+FKGGNMBk+QUr2gwfDdTJ7Q=; b=sLATxKaezlxIHcFmGZSSU/gMd2CT82OENGn+fJ2LZcuAuZ6zjjud/WdD4839lZv1FAeO/Y qNpTg+bAqTbAo1Aw== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 14A6313BB8; Mon, 25 Oct 2021 13:49:08 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id YHVVBNS1dmFtZgAAMHmgww (envelope-from ); Mon, 25 Oct 2021 13:49:08 +0000 Message-ID: <91d4688e-db6e-0ba3-e747-e995f255634b@suse.cz> Date: Mon, 25 Oct 2021 15:49:07 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Content-Language: en-US To: Johannes Weiner , linux-mm@kvack.org, Matthew Wilcox Cc: Kent Overstreet , "Kirill A. Shutemov" , Michal Hocko , Roman Gushchin , linux-kernel@vger.kernel.org, kernel-team@fb.com References: <20211012180148.1669685-1-hannes@cmpxchg.org> From: Vlastimil Babka Subject: Re: [PATCH 00/11] PageSlab: eliminate unnecessary compound_head() calls In-Reply-To: <20211012180148.1669685-1-hannes@cmpxchg.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/12/21 20:01, Johannes Weiner wrote: > PageSlab() currently imposes a compound_head() call on all callsites > even though only very few situations encounter tailpages. This short > series bubbles tailpage resolution up to the few sites that need it, > and eliminates it everywhere else. > > This is a stand-alone improvement. However, it's inspired by Willy's > patches to split struct slab from struct page. Those patches currently > resolve a slab object pointer to its struct slab as follows: > > slab = virt_to_slab(p); /* tailpage resolution */ > if (slab_test_cache(slab)) { /* slab or page alloc bypass? */ > do_slab_stuff(slab); > } else { > page = (struct page *)slab; > do_page_stuff(page); > } > > which makes struct slab an ambiguous type that needs to self-identify > with the slab_test_cache() test (which in turn relies on PG_slab in > the flags field shared between page and slab). > > It would be preferable to do: > > page = virt_to_head_page(p); /* tailpage resolution */ > if (PageSlab(page)) { /* slab or page alloc bypass? */ > slab = page_slab(page); > do_slab_stuff(slab); > } else { > do_page_stuff(page); > } I agree with this. Also not fond of introducing setting PG_slab on all tail pages as willy proposed. But also would like to avoid the tree-wide changes to PageSlab tailpage resolution that this series is doing. What we could do is what you suggest above, but the few hotpaths in slab itself would use a __PageSlab() variant that just doesn't do tailpage resolution. The rest of tree could keep doing PageSlab with tailpage resolution for now, and then we can improve on that later. Would that be acceptable? With that I'm proposing to take over willy's series (as he asked for that in the cover letter) which would be modified in the above sense. And maybe in other ways I can't immediately predict. But I do want to at least try an approach where we would deal with the "boundary" functions first (that need to deal with struct page) and then convert the bulk of "struct page" to "struct slab" at once with help of a coccinelle semantic patch. I'm hoping that this wouldn't thus be a "slapdash" conversion, while avoiding a large series of incremental patches - because the result of such automation wouldn't need such close manual review as human-written patches do. > and leave the ambiguity and the need to self-identify with struct > page, so that struct slab is a strong and unambiguous type, and a > non-NULL struct slab encountered in the wild is always a valid object > without the need to check another dedicated flag for validity first. > > However, because PageSlab() currently implies tailpage resolution, > writing the virt->slab lookup in the preferred way would add yet more > unnecessary compound_head() call to the hottest MM paths. > > The page flag helpers should eventually all be weaned off of those > compound_head() calls for their unnecessary overhead alone. But this > one in particular is now getting in the way of writing code in the > preferred manner, and bleeding page ambiguity into the new types that > are supposed to eliminate specifically that. It's ripe for a cleanup. > > Based on v5.15-rc4. > > arch/ia64/kernel/mca_drv.c | 2 +- > drivers/ata/libata-sff.c | 2 +- > fs/proc/page.c | 12 +++++++----- > include/linux/net.h | 2 +- > include/linux/page-flags.h | 10 +++++----- > mm/kasan/generic.c | 2 +- > mm/kasan/kasan.h | 2 +- > mm/kasan/report.c | 4 ++-- > mm/kasan/report_tags.c | 2 +- > mm/memory-failure.c | 6 +++--- > mm/memory.c | 3 ++- > mm/slab.h | 2 +- > mm/slob.c | 4 ++-- > mm/slub.c | 6 +++--- > mm/util.c | 2 +- > 15 files changed, 32 insertions(+), 29 deletions(-) > > >