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=-13.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable 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 AFDC2C4727E for ; Thu, 1 Oct 2020 07:17:33 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0FD1321531 for ; Thu, 1 Oct 2020 07:17:32 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0FD1321531 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 2D3056B005C; Thu, 1 Oct 2020 03:17:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 283086B0062; Thu, 1 Oct 2020 03:17:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 199668E0001; Thu, 1 Oct 2020 03:17:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0157.hostedemail.com [216.40.44.157]) by kanga.kvack.org (Postfix) with ESMTP id 0148D6B005C for ; Thu, 1 Oct 2020 03:17:31 -0400 (EDT) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id B0B4E180ACEFC for ; Thu, 1 Oct 2020 07:17:31 +0000 (UTC) X-FDA: 77322501102.04.verse89_17085f127199 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin04.hostedemail.com (Postfix) with ESMTP id 96504800BAAB for ; Thu, 1 Oct 2020 07:17:31 +0000 (UTC) X-HE-Tag: verse89_17085f127199 X-Filterd-Recvd-Size: 4574 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf17.hostedemail.com (Postfix) with ESMTP for ; Thu, 1 Oct 2020 07:17:30 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 52AF5B203; Thu, 1 Oct 2020 07:17:29 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id C839D1E10D0; Thu, 1 Oct 2020 09:17:28 +0200 (CEST) Date: Thu, 1 Oct 2020 09:17:28 +0200 From: Jan Kara To: Matthew Wilcox Cc: Jan Kara , linux-mm@kvack.org, Andrew Morton , Hugh Dickins , William Kucharski , Johannes Weiner , Yang Shi , Dave Chinner , linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 12/12] mm/filemap: Return only head pages from find_get_entries Message-ID: <20201001071728.GA17860@quack2.suse.cz> References: <20200914130042.11442-1-willy@infradead.org> <20200914130042.11442-13-willy@infradead.org> <20200930121512.GT10896@quack2.suse.cz> <20200930123637.GP20115@casper.infradead.org> <20200930170807.GA15977@quack2.suse.cz> <20200930172321.GS20115@casper.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200930172321.GS20115@casper.infradead.org> User-Agent: Mutt/1.10.1 (2018-07-13) 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 30-09-20 18:23:21, Matthew Wilcox wrote: > On Wed, Sep 30, 2020 at 07:08:07PM +0200, Jan Kara wrote: > > On Wed 30-09-20 13:36:37, Matthew Wilcox wrote: > > > On Wed, Sep 30, 2020 at 02:15:12PM +0200, Jan Kara wrote: > > > > On Mon 14-09-20 14:00:42, Matthew Wilcox (Oracle) wrote: > > > > > All callers now expect head (and base) pages, and can handle multiple > > > > > head pages in a single batch, so make find_get_entries() behave that way. > > > > > Also take the opportunity to make it use the pagevec infrastructure > > > > > instead of open-coding how pvecs behave. This has the side-effect of > > > > > being able to append to a pagevec with existing contents, although we > > > > > don't make use of that functionality anywhere yet. > > > > > > > > > > Signed-off-by: Matthew Wilcox (Oracle) > > > > > > > > Looks good to me. You can add: > > > > > > > > Reviewed-by: Jan Kara > > > > > > > > I'm just curious: What has happened to pagevec_lookup_entries() call in > > > > invalidate_inode_pages2_range()? Your series appears to be based on a tree > > > > where the call already does not exist... > > > > > > That went away in patch 10 of this series. > > > > Ah, I see. Thanks. Then I'm somewhat wondering is really > > invalidate_inode_pages2_range() safe for THP head pages? At least the: > > > > unmap_mapping_pages(mapping, index, 1, false); > > > > doesn't look adequate for THP head pages... do_launder_page() is also > > doubtful but probably currently OK because THPs cannot be dirty at this > > moment. But how about THPs that are partialy inside start-end range? So far > > the function didn't care because it was operating on page basis so it > > didn't care but now it is probably relevant... At least it would warrant a > > comment in some changelog if you are convinced everything is safe. > > You're right, it's inadequate. It's safe to apply this series to the > mainline as-is because the only filesystem which creates THP today > is tmpfs and it won't call invalidate_inode_pages2_range() (afaics). Yeah, correct. > I have a followup patch which isn't part of this series which fixes it: > > http://git.infradead.org/users/willy/pagecache.git/commitdiff/364283163847d1c106463223b858308c730592a1 Yeah, that looks good. How about partial THPs? The way you've implemented it we will now possibly evict more than strictly required. But OTOH evicting exactly may require THP split which is a bit unfortunate. But probably still a better option because otherwise we could have pages being repeatedly brought in and out of cache just because e.g. workload mixes direct and buffered IO and is not aligned to THP boundary (and although I find loads mixing buffered and direct IO to the same file badly designed, I know for a fact that they do exist and if the file ranges are not overlapping, it is not that insane design). Honza -- Jan Kara SUSE Labs, CR