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 F0C0BC433FE for ; Mon, 21 Nov 2022 17:17:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6D92C6B0072; Mon, 21 Nov 2022 12:17:29 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 68A4A6B0073; Mon, 21 Nov 2022 12:17:29 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 52A176B0074; Mon, 21 Nov 2022 12:17:29 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 426D16B0072 for ; Mon, 21 Nov 2022 12:17:29 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 143E51C5AC4 for ; Mon, 21 Nov 2022 17:17:29 +0000 (UTC) X-FDA: 80158105818.11.BE31555 Received: from mail-qv1-f43.google.com (mail-qv1-f43.google.com [209.85.219.43]) by imf07.hostedemail.com (Postfix) with ESMTP id 0A9E940010 for ; Mon, 21 Nov 2022 17:17:26 +0000 (UTC) Received: by mail-qv1-f43.google.com with SMTP id h10so8413574qvq.7 for ; Mon, 21 Nov 2022 09:17:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=i/VbYzsnoDE2k0Jj4uL/vSZLNIjl3EQx0mm05ELH+/A=; b=SvPg1Ztvqfsah6gG0PV9vXMlY7b7QctK404v8Y3iQFhXamQOz8sDneWIPMDDajhp1i G9aPIymQ8yfBh+kzb/C8LfxfF5LgGKVHzuHFr6c96/J/nLydPegcrikWa8Sl9y/aXbPO YYxBcHwur972W656iStWTcS4nNFTfczO0mRjk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=i/VbYzsnoDE2k0Jj4uL/vSZLNIjl3EQx0mm05ELH+/A=; b=gUBonZl+eJ76Gy3/UaWMrxSslDH22ljFbFX2YDuL+wPrkq48a8Z0L5sjPbLB3PgsAD RqUWbM9hEhoGosiEVE7W46z0VBbtsSTNO8ET0GUBQmsuRT22EaExzmyWuu7ySwB1s8vh O3ANVvcMRV02vu8GPFZQAK3XZob3qbYvU2FW98CAIIsJXCpuRzjB+lhEjLoMqNfS42Z9 sqcG1uW01dOBAPMaFyi7Hl1zOF6FW06DVpofttNToO5nELKBl6Du9jVdpJ0BS4zahJm+ C3WZyEPLb2ktB2KbOukD96CT6TL5tS6lgVKC6BirVh7R+wHXOZvI94Iujhy7u6HSXZpI M3XA== X-Gm-Message-State: ANoB5plJPtBOAwKpN7nlw/WRu6ZEdzyDAhradv/VwE/wtlDjTANQ8h8W nmqdvoP4KTh4VPRFbwaY33KYgY4HbVkoBA== X-Google-Smtp-Source: AA0mqf7LeI1eIqZa2JyrSA+xMf2/tqTiHG5oVKYGVBEJxCy1djan2yY5Su/po4/vw/F+AxEJKqaoew== X-Received: by 2002:a05:6214:170e:b0:4b4:95b9:674f with SMTP id db14-20020a056214170e00b004b495b9674fmr698380qvb.110.1669051045840; Mon, 21 Nov 2022 09:17:25 -0800 (PST) Received: from mail-qt1-f177.google.com (mail-qt1-f177.google.com. [209.85.160.177]) by smtp.gmail.com with ESMTPSA id a11-20020ac8108b000000b0035d08c1da35sm6867333qtj.45.2022.11.21.09.17.25 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Nov 2022 09:17:25 -0800 (PST) Received: by mail-qt1-f177.google.com with SMTP id w4so7716619qts.0 for ; Mon, 21 Nov 2022 09:17:25 -0800 (PST) X-Received: by 2002:ac8:41cd:0:b0:3a5:1ba7:717d with SMTP id o13-20020ac841cd000000b003a51ba7717dmr18464445qtm.678.1669051034241; Mon, 21 Nov 2022 09:17:14 -0800 (PST) MIME-Version: 1.0 References: <5f52de70-975-e94f-f141-543765736181@google.com> <20221121165938.oid3pemsfkaeq3ws@google.com> In-Reply-To: <20221121165938.oid3pemsfkaeq3ws@google.com> From: Linus Torvalds Date: Mon, 21 Nov 2022 09:16:58 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 0/3] mm,thp,rmap: rework the use of subpages_mapcount To: Shakeel Butt Cc: Hugh Dickins , Andrew Morton , Johannes Weiner , "Kirill A. Shutemov" , Matthew Wilcox , David Hildenbrand , Vlastimil Babka , Peter Xu , Yang Shi , John Hubbard , Mike Kravetz , Sidhartha Kumar , Muchun Song , Miaohe Lin , Naoya Horiguchi , Mina Almasry , James Houghton , "Zach O'Keefe" , linux-kernel@vger.kernel.org, linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=SvPg1Ztv; spf=pass (imf07.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.219.43 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669051047; a=rsa-sha256; cv=none; b=2CEUK1lL+wr8fFBQhUGMIWgtgrpThZbUeiQ28QZBg69Ev8VDbRi+NBp+CBE7aa4Vbi8iYc JC7qWdtDmo+lnq2oJWhUbHLCG6tZ2P6o84NrqnscN3XITM2HEkQlxyhJQs41UEQK2c/ocr OqXdVE/uuKrs61gR4o5NzmVGy7pU/6s= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1669051047; 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=i/VbYzsnoDE2k0Jj4uL/vSZLNIjl3EQx0mm05ELH+/A=; b=bZOrmzl+emy1DWqMFcQ8y1YtBLQddd3Iypx2Rbqle8nT+u+sO31THuge5/Bg6V9O6aSd2E kdzZiHeq5/HI1Drd1knJ5VWOV2zDdgXN0j2u2xmYSvZSw1yy2PWKO6IwvPNmgnDUwRP1fG GGjb+nkk+JAB5r/9VbO6FzUM39H1TtM= X-Rspam-User: Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=SvPg1Ztv; spf=pass (imf07.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.219.43 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none X-Stat-Signature: cjzdnos1oxzf84ukensawr7ioctwp7rh X-Rspamd-Queue-Id: 0A9E940010 X-Rspamd-Server: rspam09 X-HE-Tag: 1669051046-407303 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 Mon, Nov 21, 2022 at 8:59 AM Shakeel Butt wrote: > > Is there a plan to remove lock_page_memcg() altogether which I missed? I > am planning to make lock_page_memcg() a nop for cgroup-v2 (as it shows > up in the perf profile on exit path) Yay. It seems I'm not the only one hating it. > but if we are removing it then I should just wait. Well, I think Johannes was saying that at least the case I disliked (the rmap removal from the page table tear-down - I strongly suspect it's the one you're seeing on your perf profile too) can be removed entirely as long as it's done under the page table lock (which my final version of the rmap delaying still was). See https://lore.kernel.org/all/Y2llcRiDLHc2kg%2FN@cmpxchg.org/ for his preliminary patch. That said, if you have some patch to make it a no-op for _other_ reasons, and could be done away with _entirely_ (not just for rmap), then that would be even better. I am not a fan of that lock in general, but in the teardown rmap path it's actively horrifying because it is taken one page at a time. So it's taken a *lot* (although you might not see it if all you run is long-running benchmarks - it's mainly the "run lots of small scripts that really hits it). The reason it seems to be so horrifyingly noticeable on the exit path is that the fork() side already does the rmap stuff (mainly __page_dup_rmap()) _without_ having to do the lock_page_memcg() dance. So I really hate that lock. It's completely inconsistent, and it all feels very wrong. It seemed entirely pointless when I was looking at the rmap removal path for a single page. The fact that both you and Johannes seem to be more than ready to just remove it makes me much happier, because I've never actually known the memcg code enough to do anything about my simmering hatred. Linus