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 3F536C433F5 for ; Fri, 4 Mar 2022 05:26:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CD16F8D0002; Fri, 4 Mar 2022 00:26:27 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C81818D0001; Fri, 4 Mar 2022 00:26:27 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B71CE8D0002; Fri, 4 Mar 2022 00:26:27 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0060.hostedemail.com [216.40.44.60]) by kanga.kvack.org (Postfix) with ESMTP id A99818D0001 for ; Fri, 4 Mar 2022 00:26:27 -0500 (EST) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 52067181BF883 for ; Fri, 4 Mar 2022 05:26:27 +0000 (UTC) X-FDA: 79205568414.28.B4EB798 Received: from mail-qk1-f175.google.com (mail-qk1-f175.google.com [209.85.222.175]) by imf24.hostedemail.com (Postfix) with ESMTP id C90DD180009 for ; Fri, 4 Mar 2022 05:26:26 +0000 (UTC) Received: by mail-qk1-f175.google.com with SMTP id bm39so5751011qkb.0 for ; Thu, 03 Mar 2022 21:26:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version; bh=QrGr+Bl6A1eU/fulzKdJtDbWBbVCzUvn4PhrHXLHZ0A=; b=sSwqaIpdVCk4KE77NO/JzSErM9U9UpCb1GP4qocamsBiiP83n/xlhn/YgRuDoZo29/ Qr6NT+8HOo3itBaNIRAGMkNHeGfnv8nrHiDZeharfJ9cVE755PBslYon40b+lSkPsjcq CZ6HG3LSVpO6BO45TeEEu7A1o8mzcQrxquPKwjFlHtTrvP8Qw+HZ60B3rSu4TljFVjgz wlqJ5XUyLZKBxK1xakpDh7wuqi0FvJ2qnAjzJdOSzyARYxLi/hbug7NJCcwtJ7ZGq+Cs b7IbVu30i+pUNEKDlGDoGYaZFz4tikuvmxc8q+bh/mzuVycDoRzImQZrA7h7Ma0v0MZn eerA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:mime-version; bh=QrGr+Bl6A1eU/fulzKdJtDbWBbVCzUvn4PhrHXLHZ0A=; b=Lyghb8z7pCeOzVEylSxTaQPxFN2zLe4RtfxUXIS3SN2sYLwcu1pawcxXoOiq+nv1Oj s5Zh1lVwKoCW9xDzWRdf7h8uDm5uKxjfyyosIwBA4jhzNcVp1X6mAeVH0sb8vRprpSEq EPBBFHZyWkw2mOQD2CMVFniRcmmGly9h/6odPwnLhleVaB5gVfzVNBM26t/p9UVjxtbF OkPmMrcrG2w2CEgmH0NMF2nQ0FN+bxMc3hnuuvZnWSAkp4uxAfUl2oT6jIVxm/8wjwTk icSgRbI46ecBM5+EPL/4KOl8/6cuyHHVjJAsapLmt411/682ZsA8wife493t9IRCmM5V q8VA== X-Gm-Message-State: AOAM533beu8WntpnTlVEftjCsLdO9cV+lvZSb5SiZNDjlC4ApjMaCa8G SjHtIgCkipjQ4sQT9sfN4KwQcQ== X-Google-Smtp-Source: ABdhPJxgIPX0A86WyaHHgPvqN0279b+mgbfO5Ggd0HZDymV7s19wwX88jcTIs8D9mWC79zMQi/XKnQ== X-Received: by 2002:a05:620a:137c:b0:648:e909:e9f with SMTP id d28-20020a05620a137c00b00648e9090e9fmr1536380qkl.313.1646371585886; Thu, 03 Mar 2022 21:26:25 -0800 (PST) Received: from ripple.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id b137-20020ae9eb8f000000b00648f9736ab0sm1994744qkg.124.2022.03.03.21.26.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 03 Mar 2022 21:26:25 -0800 (PST) Date: Thu, 3 Mar 2022 21:26:15 -0800 (PST) From: Hugh Dickins X-X-Sender: hugh@ripple.anvils To: Matthew Wilcox cc: Hugh Dickins , Andrew Morton , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH mmotm] mm: filemap_unaccount_folio() large skip mapcount fixup In-Reply-To: Message-ID: <3251e132-35e0-8185-b528-faaa6f3c612@google.com> References: <879c4426-4122-da9c-1a86-697f2c9a083@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: C90DD180009 X-Stat-Signature: gpzh1dpcu55bdfkbdd3qmdc57rw9cnip Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=sSwqaIpd; spf=pass (imf24.hostedemail.com: domain of hughd@google.com designates 209.85.222.175 as permitted sender) smtp.mailfrom=hughd@google.com; dmarc=pass (policy=reject) header.from=google.com X-HE-Tag: 1646371586-260194 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, 4 Mar 2022, Matthew Wilcox wrote: > On Thu, Mar 03, 2022 at 08:21:19PM -0800, Hugh Dickins wrote: > > The page_mapcount_reset() when folio_mapped() while mapping_exiting() > > was devised long before there were huge or compound pages in the cache. > > It is still valid for small pages, but not at all clear what's right to > > check and reset on large pages. Just don't try when folio_test_large(). > > Thanks for bringing this up! I was really unsure about this chunk of code > when converting unaccount_page_cache_page() to filemap_unaccount_folio(). > > Part of me wants to just delete the whole thing. A part of me feels the same way. Accepting to waste 2MB while footling around over 4kB doesn't help my case for that code - whose beauty is, umm, questionable. > I'm unconvinced by > the argument; surely it's better to leak memory than perhaps reuse a > page which should not have been freed yet? I know people who would agree with you. And in most cases we do prefer to waste it, because it has become suspicious. But by far the most common reason for getting here, is that a page table has got corrupted in some way, so the pte or pmd was never identified to unmap the page. Nothing suspect about the page itself, and (barring a bug in vma unlinking) all the mappings which might hold the page have been unmapped: we've just got a leftover in the mapcount. > > Also, the code doesn't take into account that folio_mapped() is freaking > expensive for THP (512 cache lines, blowing away 32kB of your L1 cache!), > and we may as well calculate folio_mapcount() while we're doing it. Well, we don't need to optimize the rare case. As you know, I've long thought that there should be one quick total mapcount field; but it's never been a priority to work out the details on that (and Linus seems to be driving mapcount out of fashion; and you have your own ideas there). > > Do you see this report often on machines that don't have > VM_BUG_ON_FOLIO() enabled? No, not often at all. Almost never. I think it did come up occasionally when that code was written, but seems to have faded away in recent years. Cosmic rays getting weaker, or memory getting better, or fewer bugs perhaps - I haven't looked back to check, may be wrong, but I think when I added unmap_mapping_page() last year (now s/page/folio/), that was to fix one real (but benign) cause of such warnings. Hugh