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=-9.9 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1,USER_IN_DEF_DKIM_WL 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 EF814C4BA24 for ; Thu, 27 Feb 2020 01:37:27 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id AE0BF208E4 for ; Thu, 27 Feb 2020 01:37:27 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="mXd5SVYY" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AE0BF208E4 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 408016B0003; Wed, 26 Feb 2020 20:37:27 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3B7966B0005; Wed, 26 Feb 2020 20:37:27 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2CCA06B0006; Wed, 26 Feb 2020 20:37:27 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0004.hostedemail.com [216.40.44.4]) by kanga.kvack.org (Postfix) with ESMTP id 142106B0003 for ; Wed, 26 Feb 2020 20:37:27 -0500 (EST) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id BBE7F181AC9CB for ; Thu, 27 Feb 2020 01:37:26 +0000 (UTC) X-FDA: 76534194492.21.town48_40ef28a19ff20 X-HE-Tag: town48_40ef28a19ff20 X-Filterd-Recvd-Size: 6328 Received: from mail-pl1-f196.google.com (mail-pl1-f196.google.com [209.85.214.196]) by imf24.hostedemail.com (Postfix) with ESMTP for ; Thu, 27 Feb 2020 01:37:26 +0000 (UTC) Received: by mail-pl1-f196.google.com with SMTP id y1so433872plp.7 for ; Wed, 26 Feb 2020 17:37:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=vZDwfNLVUBH6SGm2FcQoiJLrDZVGLDDEbJUTgzVuEvs=; b=mXd5SVYYTzZ17GeQ+3kEKesccxr9w0WIIKJiKARi3WPT7EYMzXv3gdtI/z344fipaC VfFDEZNUUAJyhUSvlQc4+8Db8BZmXG/l9lcTBaOEmXWnqnr/WlcSIbNCRdkap2IIpH9E FVAZisCtnUFEV4sazZsGkW+lwxr54D99nLRMaN3uU2lXNSdMn+0VLmZ63Np7r1BSVP7Q /ZjTH20IRBm80xiwEWzIaeBhFfoXjaRe9mVPo4LZ7kf3OJR3mSGvHUWS2hHW4yao3uL1 TGB6xES+l4itrLSdjHGHyEDg4xOQQ1snSsMA0uIy4MO/gkKahmYYoS/He2VKiWhmVNqW 1mbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version; bh=vZDwfNLVUBH6SGm2FcQoiJLrDZVGLDDEbJUTgzVuEvs=; b=OzZkTTkwh57ECi0lBZJSCCzixV+xcMQNEHmXunr05OHAndv1R1UfmjVY7rvlMVafW5 hHw1Tz5YCP7q5o7M7h6FZLpDrk+Hji5gSDocutMb7ZuLdhKgygsGK6Z6EAsk3Bpgnym8 f41h6Ox4CvXSnB+TRkuqEsXu2WPx2IENC35tGUpNX5CPywIw+feOxkAu7po6BAxJ2kp1 TKM02xdgY7plfuWjTZTGfihxcdHi8/xBmzwzhehTPvn77pwb8ly3wde0qiUfLyb9Ch9X mVCIIXnZS2vNpWDvatoYCS9N0PqKll/KgmX73z8rrknPH0TqljtwKgmKGsj5KFqXwi6Q xVLQ== X-Gm-Message-State: APjAAAWft2U98ZW6JH/lvGrk0G/Rim9gstGhZOSnJIR0VOonJ6VxzO6K OUZnt0SLHECVxeJZ08pKPjKjkw== X-Google-Smtp-Source: APXvYqxEmhYf4O6qUNGfO+tvwPPmEsOadkT+TrXOCj8bNk3niEzy0lP75wQarqV47KyQlNjty9UfDg== X-Received: by 2002:a17:90a:3603:: with SMTP id s3mr2152716pjb.61.1582767444239; Wed, 26 Feb 2020 17:37:24 -0800 (PST) Received: from [100.112.92.218] ([104.133.9.106]) by smtp.gmail.com with ESMTPSA id w11sm4037509pgh.5.2020.02.26.17.37.23 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 26 Feb 2020 17:37:23 -0800 (PST) Date: Wed, 26 Feb 2020 17:37:22 -0800 (PST) From: Hugh Dickins X-X-Sender: hugh@eggly.anvils To: Yang Shi cc: Hugh Dickins , kirill.shutemov@linux.intel.com, aarcange@redhat.com, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [v2 PATCH] mm: shmem: allow split THP when truncating THP partially In-Reply-To: Message-ID: References: <1575420174-19171-1-git-send-email-yang.shi@linux.alibaba.com> <00f0bb7d-3c25-a65f-ea94-3e2de8e9bcdd@linux.alibaba.com> User-Agent: Alpine 2.11 (LSU 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Wed, 26 Feb 2020, Yang Shi wrote: > On 2/24/20 7:46 PM, Hugh Dickins wrote: > > > > I did willingly call my find_get_entries() stopping at PageTransCompound > > a hack; but now think we should just document that behavior and accept it. > > The contortions of your patch come from the need to release those 14 extra > > unwanted references: much better not to get them in the first place. > > > > Neither of us handle a failed split optimally, we treat every tail as an > > opportunity to retry: which is good to recover from transient failures, > > but probably excessive. And we both have to restart the pagevec after > > each attempt, but at least I don't get 14 unwanted extras each time. > > > > What of other find_get_entries() users and its pagevec_lookup_entries() > > wrapper: does an argument to select this "stop at PageTransCompound" > > behavior need to be added? > > > > No. The pagevec_lookup_entries() calls from mm/truncate.c prefer the > > new behavior - evicting the head from page cache removes all the tails > > along with it, so getting the tails a waste of time there too, just as > > it was in shmem_undo_range(). > > TBH I'm not a fun of this hack. This would bring in other confusion or > complexity. Pagevec is supposed to count in the number of base page, now it > would treat THP as one page, and there might be mixed base page and THP in > one pagevec. I agree that it would be horrid if find_get_entries() and pagevec_lookup_entries() were switched to returning just one page for a THP, demanding all callers to cope with its huge size along with the small sizes of other pages in the vector. I don't know how to get such an interface to work at all: it's essential to be able to deliver tail pages from a requested offset in the compound page. No, that's not what the find_get_entries() modification does: it takes advantage of the fact that no caller expects it to guarantee a full pagevec, so terminates the pagevec early when it encounters any head or tail subpage of the compound page. Then the next call to it (if caller does not have code to skip the extent - which removal of head from page cache does) returns just the next tail, etc, until all have been delivered. All as small pages. (Aside from the comments, I have made one adjustment to what I showed before: though it appears now that hugetlbfs happens not to use pagevec_lookup_entries(), not directly anyway, I'm more comfortable checking PageTransHuge && !PageHuge, so that it would not go one-at-a-time on hugetlbfs pages. But found I was wrong earlier when I said the "page->index + HPAGE_PMD_NR <= end" test needed correcting for 32-bit: it's working on PageHead there, so there's no chance of that "+ HPAGE_PMD_NR" wrapping around: left unchanged, what it's doing is clearer that way than with macros.) Hugh > But, I tend to agree avoiding getting those 14 extra pins at the > first place might be a better approach. All the complexity are used to > release those extra pins.