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 X-Spam-Level: X-Spam-Status: No, score=-2.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AC33EC433FE for ; Fri, 24 Sep 2021 03:26:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 91FF861242 for ; Fri, 24 Sep 2021 03:26:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244007AbhIXD2J (ORCPT ); Thu, 23 Sep 2021 23:28:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56430 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235369AbhIXD2I (ORCPT ); Thu, 23 Sep 2021 23:28:08 -0400 Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DB85CC061574; Thu, 23 Sep 2021 20:26:35 -0700 (PDT) Received: by mail-ed1-x52b.google.com with SMTP id x7so16142025edd.6; Thu, 23 Sep 2021 20:26:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=18+5whvcDDqdfxVcWTrxiz/OMweHZu0w3dsMvDPd2x0=; b=QeO0RCPobSsavCWYY1RbFVToa8iXjat5Qhm4VBQxlUm8I2uKeCUnUZqnUXZPWvTP3I 3DkSgeXKY1Vt64niNrSkNlCd4fBfPVoA/UGBmSCZMmAoVvWUWiLpk4QXMB0w7kjeR4DZ 0+BsnPbGwScxAb5hvUFXNw5mAyFEP6imQdbAYvmmKMqsd7QuiLKIlkXZ0dm+Ls9Pe30H Ac1b3UVSbo2CZwTPGiDFVSTZaomfC6ERWSf88p5yWuIuC2R9FQyBOI3Vgw31py0Tun6e 3Cz2Zr0Umq4IAQIn1kMpdQPKZBuQKoeDNs12wOujkEONRU9qJoAuxbXO9D78tqXS4kCr cajA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=18+5whvcDDqdfxVcWTrxiz/OMweHZu0w3dsMvDPd2x0=; b=6XP3S/OwN79O+aSQAMsGo3RLapv25g56YARkgjZprtX62ETPI9kSe+cAkpZ+vKihtO tbqjg412RP7iCGoHD6e/TKQE+9T2ISsadJPbH+Xzql6jxs04jMZlHH65gEPpt0Ri7QXj LUFno5T4IkfzogYmRzgR6kjQeEn7HsSeqwazRlgKDumhP5iEo6jd00SNzqPyunJJ3quh 66v0r23II2rXhtAhN0oKXeqVwayGZVBD5SxupP/rBmPjv07JaofWCVBCw9Qh/g1TLa28 RbFFC9QTrGYZx6J3WQF5h7tm8/5DITVOk+LX9ciCncDZmxMGKkUXS8X67RdTl30ChRbg eDZQ== X-Gm-Message-State: AOAM530wKJQiKWbRHI6M1LQ61CwY1gak5THlX2FUy0bbjUm8swX4Kkjv vvYtb98+FqCXEF8a7SB0roFzFcro5SNqc4dpv0Y= X-Google-Smtp-Source: ABdhPJyTRNRz76PPApx+1focabGvQlQuAjrXjZcFxgXozpU4UGlOYiDD19uR1USNsAf/p6R92BCFoG9sqmBxkPq4bJ4= X-Received: by 2002:a17:906:3f83:: with SMTP id b3mr2452641ejj.233.1632453994521; Thu, 23 Sep 2021 20:26:34 -0700 (PDT) MIME-Version: 1.0 References: <20210923124502.nxfdaoiov4sysed4@box.shutemov.name> <72cc2691-5ebe-8b56-1fe8-eeb4eb4a4c74@google.com> <2A311B26-8B33-458E-B2C1-8BA2CF3484AA@nvidia.com> <77b59314-5593-1a2e-293c-b66e8235ad@google.com> In-Reply-To: From: Yang Shi Date: Thu, 23 Sep 2021 20:26:22 -0700 Message-ID: Subject: Re: Mapcount of subpages To: Matthew Wilcox Cc: Hugh Dickins , Zi Yan , "Kirill A. Shutemov" , Kent Overstreet , Linux FS-devel Mailing List , Linux Kernel Mailing List , Linux MM , Johannes Weiner , Linus Torvalds , Andrew Morton , "Darrick J. Wong" , Christoph Hellwig , David Howells , Mike Kravetz Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Thu, Sep 23, 2021 at 6:32 PM Matthew Wilcox wrote: > > On Thu, Sep 23, 2021 at 06:11:19PM -0700, Yang Shi wrote: > > On Thu, Sep 23, 2021 at 4:49 PM Hugh Dickins wrote: > > > I believe Yang Shi is right insofar as the decision on whether it's worth > > > queuing for deferred split is being done based on those subpage _mapcounts. > > > That is a use I had not considered, and I've given no thought to how > > > important or not it is. > > > > Anyway deferred split is anon THP specific. We don't have to worry > > about this for file THP. So your suggestion about just counting total > > mapcount seems feasible to me for file THP at least. > > But I think we probably *should* do deferred split for file THP. > At the moment, when we truncate to the middle of a shmem THP, we try > a few times to split it and then just give up. We should probably try > once and then queue it for deferred split. Yes, probably. Anyway this doesn't need _mapcount of subpages.