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 DFA3CC43217 for ; Thu, 20 Jan 2022 16:09:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 76C8F6B00A8; Thu, 20 Jan 2022 11:09:24 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6F4C26B00A9; Thu, 20 Jan 2022 11:09:24 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 549A26B00AB; Thu, 20 Jan 2022 11:09:24 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0136.hostedemail.com [216.40.44.136]) by kanga.kvack.org (Postfix) with ESMTP id 3FDFB6B00A8 for ; Thu, 20 Jan 2022 11:09:24 -0500 (EST) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 017098249980 for ; Thu, 20 Jan 2022 16:09:24 +0000 (UTC) X-FDA: 79051150206.25.EF8DF9C Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf29.hostedemail.com (Postfix) with ESMTP id 89A42120021 for ; Thu, 20 Jan 2022 16:09:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.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=zJ6ZyTp9w0QanKEybJL1wVq2X76sHQEksAa3eQdzWn8=; b=BdPlRD8JRTV4pEZr0B5wQ6GBlA 5mYj4H7KwJl8k+P9OLhNx39oUQUVqh+O27sCTpmIkm+3laShc0uHwi3ESZTbAcbFsbK12a56bqqVW +wS0fZHCsVHkYCgiKoiWn155QPo4VIyQ+JSiNhU+Yj3KxxovS450WqcFCcwS61YXCOJe5bFRRRKn+ fTeCdKF0ZIBoYt3aO4RTRD5HjcMb82OKThQr6+LKuhjXCFMvx1JNAnF48K4d0Ixv712TKHHMR0m5U M9RdU5u/buAAfZruSUSUIpCoeOA8l2JnffatL7avPFWFnb17tMHUo3kEvA4n4Nw4QHXfo60S+HT4w Xy9rG1tw==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1nAZzx-00EQ98-U9; Thu, 20 Jan 2022 16:09:17 +0000 Date: Thu, 20 Jan 2022 16:09:17 +0000 From: Matthew Wilcox To: David Hildenbrand Cc: "zhangliang (AG)" , Andrew Morton , Linux-MM , Linux Kernel Mailing List , wangzhigang17@huawei.com, Linus Torvalds Subject: Re: [PATCH] mm: reuse the unshared swapcache page in do_wp_page Message-ID: References: <9cd7eee2-91fd-ddb8-e47d-e8585e5baa05@redhat.com> <747ff31c-6c9e-df6c-f14d-c43aa1c77b4a@redhat.com> <759f9bc8-0b10-7f0f-28a6-f292bed9053f@redhat.com> <88a8b1a3-232d-df9c-d7f6-0ea9f2dd4b36@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <88a8b1a3-232d-df9c-d7f6-0ea9f2dd4b36@redhat.com> X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 89A42120021 X-Stat-Signature: mfztqr89t89c597f765ezmrxp1w7kzrs Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=BdPlRD8J; spf=none (imf29.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none X-HE-Tag: 1642694963-657321 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 Thu, Jan 20, 2022 at 04:51:47PM +0100, David Hildenbrand wrote: > > >> Yes, we are talking past each other and no, I am talking about fully > >> mapped THP, just mapped via PTEs. > >> > >> Please refer to our THP COW logic: do_huge_pmd_wp_page() > > > > You're going to have to be a bit more explicit. That's clearly handling > > the case where there's a PMD mapping. If there is _also_ a PTE mapping, > > then obviously the page is mapped more than once and can't be reused! > > > >>> > >>>>> Anon THP is always going to start out aligned (and can be moved by > >>>>> mremap()). Arguably it should be broken up if it's moved so it can be > >>>>> reformed into aligned THPs by khugepaged. > >>>> > >>>> Can you elaborate, I'm missing the point where something gets moved. I > >>>> don't care about mremap() at all here. > >>>> > >>>> > >>>> 1. You have a read-only, PTE mapped THP > >>>> 2. Write fault on the THP > >>>> 3. We PTE-map the THP because we run into a false positive in our COW > >>>> logic to handle COW on PTE > >>>> 4. Write fault on the PTE > >>>> 5. We always have to COW each and every sub-page and can never reuse, > >>>> because page_count() > 1 > >>>> > >>>> That's essentially what reuse_swap_page() tried to handle before. > >>>> Eventually optimizing for this is certainly the next step, but I'd like > >>>> to document which effect the removal of reuse_swap_page() will have to THP. > >>> > >>> I'm talking about step 0. How do we get a read-only, PTE-mapped THP? > >>> Through mremap() or perhaps through an mprotect()/mmap()/munmap() that > >>> failed to split the THP. > >> > >> do_huge_pmd_wp_page() > > > > I feel you could be a little more verbose about what you think is > > going on here. Are you talking about the fallback: path where we > > call __split_huge_pmd()? > > Sorry, I was less verbose because I was just sending out the > patch+description to Linus' reply and was assuming you're going to read > it anyways ;) This reply arrived before your reply to Linus ;-) Anyway ... > Yes, I'm speaking about exactly that fallback path. OK, so in that fallback path, we're already determined the THP has more than one reference to it (ok, maybe that extra reference was temporary and now gone), but we've already split the PMD down into PTEs, and COWed one of the other pages that was in the THP. If anything, we should be more aggressive about COWing the remaining pages in the THP, not looking for reasons why we might be able to avoid COWing this particular page.