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=-0.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, 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 EB590C4BA36 for ; Thu, 27 Feb 2020 01:17:06 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A681C24672 for ; Thu, 27 Feb 2020 01:17:06 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="AHnBLjn3" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A681C24672 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 529916B0005; Wed, 26 Feb 2020 20:17:06 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4D9E76B0006; Wed, 26 Feb 2020 20:17:06 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3EE906B0007; Wed, 26 Feb 2020 20:17:06 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0208.hostedemail.com [216.40.44.208]) by kanga.kvack.org (Postfix) with ESMTP id 25BBE6B0005 for ; Wed, 26 Feb 2020 20:17:06 -0500 (EST) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id CE524180AD811 for ; Thu, 27 Feb 2020 01:17:05 +0000 (UTC) X-FDA: 76534143210.07.army15_20c15bcb1482a X-HE-Tag: army15_20c15bcb1482a X-Filterd-Recvd-Size: 2955 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) by imf35.hostedemail.com (Postfix) with ESMTP for ; Thu, 27 Feb 2020 01:17:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=xzybkCZjTyLb0VqFQbFVRWtDGZw2aWyH8QFRYq4X5ek=; b=AHnBLjn3kbXNGq+iIcAM/IqPeG JZYPRLDzH7mPdDTuloPqFSuLzcF3h5TA8TZ4QYrkW8bWechx/eIpBwyF1LJay4svFJHUuFA648xqX wXZAFNIqO7iCCPjs+rOzUQb6vxKMzXp1PoZO2AhjwRwn1XeYj0Z6L3t8I4z3UNu9F+P6Nfl85cGmN y18ZvmzNBv3xFkEHZADGZ80vlsuzY3W2PuItl54mWN2ZiRqTGmO1a6b3jxPNt+8//WDbPzLS7TWW/ lKx6yfrVHEpEa0aQKFGmANPhjbIdFBkBprRE9MrPO7uiMyYmJ/L4q26nIRVBhIHudGH8+KBXfyZ/u BDF+0EVQ==; Received: from willy by bombadil.infradead.org with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1j77nK-0003bv-44; Thu, 27 Feb 2020 01:16:54 +0000 Date: Wed, 26 Feb 2020 17:16:54 -0800 From: Matthew Wilcox 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 Message-ID: <20200227011654.GF24185@bombadil.infradead.org> References: <1575420174-19171-1-git-send-email-yang.shi@linux.alibaba.com> <00f0bb7d-3c25-a65f-ea94-3e2de8e9bcdd@linux.alibaba.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Bogosity: Ham, tests=bogofilter, spamicity=0.000108, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Feb 26, 2020 at 09:43:53AM -0800, Yang Shi wrote: > > 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. 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. My long-term goal is to eradicate tail pages entirely, so a pagevec will end up containing pages of different sizes. If you want to help move in this direction, I'd be awfully grateful. But I wouldn't say that's in any way a prerequisite for fixing this current problem.