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 254F9C433F5 for ; Fri, 21 Jan 2022 05:11:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 188466B007D; Fri, 21 Jan 2022 00:11:41 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 138416B007E; Fri, 21 Jan 2022 00:11:41 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F417D6B0080; Fri, 21 Jan 2022 00:11:40 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay034.a.hostedemail.com [64.99.140.34]) by kanga.kvack.org (Postfix) with ESMTP id E229B6B007D for ; Fri, 21 Jan 2022 00:11:40 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 9AF6120CBE for ; Fri, 21 Jan 2022 05:11:40 +0000 (UTC) X-FDA: 79053121560.02.6CA9AAD Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf28.hostedemail.com (Postfix) with ESMTP id 0C82AC0008 for ; Fri, 21 Jan 2022 05:11:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1642741899; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=L0wOMdBYCyHlL69KsDd6YPdAUhkVTm6hlziUz50KanQ=; b=RhmzszADGXsHu+YCINZp7IU7r1ZbOdmmFr++7LU/YoXVwx7D6OZ4eGxpATLE7aL3SU4rSm /0hkLRsCTNuI14f/B1ymCL8LajliDN8jkre0Y2LrM205jg3LM/leuwKUnNLL4KO9obO2jD wZq4OloWb6hRioRG0iJ/YcNdhIzFXFg= Received: from mail-pg1-f198.google.com (mail-pg1-f198.google.com [209.85.215.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-625-QqxNZL1OOC2AJod0SW4zyg-1; Fri, 21 Jan 2022 00:11:38 -0500 X-MC-Unique: QqxNZL1OOC2AJod0SW4zyg-1 Received: by mail-pg1-f198.google.com with SMTP id q3-20020a638c43000000b0034c9c0fb2d2so4995864pgn.22 for ; Thu, 20 Jan 2022 21:11:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=L0wOMdBYCyHlL69KsDd6YPdAUhkVTm6hlziUz50KanQ=; b=7SuVQzQxHH5GG24z0Av2NtLY9fNwS9koz2UD5J+7wopbw+xtErFUti/EfHqVy/tvtj LIXiWwVjH3lHP7E0NfwbPq5Ny9QOtDIL9/zAPsfgakskOadc6/RlARmUQPCSn6BvJs2v 7PSDrxJA9HoMeUrMB2Qh5elsHT80HFh6nDJuoxHddcSL/nFIhCx154pKSjhmxl+AFWOB YgqGlc1INDACwccaum67DVwUfZyRcnI6Rqix4v5/9j4ySKWD1T4yrG9rObuRdp7CxUxa JqWpL6MrEyqThehKUJqPqkxZsBJhCbteIgVGHNe3D0iPiXdiCc6wGFi+y68mgX8Ve5LM 75WA== X-Gm-Message-State: AOAM531jLUUzvxKnGg2U0/VKDPJVXNvz5UP39iu1BZVOesMnlqzDxRm0 LP2NMpDUPE6/yC0GkS+17aLyhrMtJ1PBqJNFb13PR00YrZaPNpXWd0xHiob1fj4Wb0bRsz07Ql1 m7uBu0j3DmKA= X-Received: by 2002:a17:902:ce8d:b0:14a:70dc:2050 with SMTP id f13-20020a170902ce8d00b0014a70dc2050mr2244419plg.11.1642741897052; Thu, 20 Jan 2022 21:11:37 -0800 (PST) X-Google-Smtp-Source: ABdhPJzRcsiVOFuX+avW7yYJ2HGJbIr7G7j9yQrgquRGZxjg0u6Uup+RYwh35T8s1mSwkgOQ53IHjw== X-Received: by 2002:a17:902:ce8d:b0:14a:70dc:2050 with SMTP id f13-20020a170902ce8d00b0014a70dc2050mr2244386plg.11.1642741896537; Thu, 20 Jan 2022 21:11:36 -0800 (PST) Received: from xz-m1.local ([94.177.118.81]) by smtp.gmail.com with ESMTPSA id n4sm3778295pjf.0.2022.01.20.21.11.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 20 Jan 2022 21:11:35 -0800 (PST) Date: Fri, 21 Jan 2022 13:11:28 +0800 From: Peter Xu To: Hugh Dickins Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, David Hildenbrand , Andrea Arcangeli , Yang Shi , Vlastimil Babka , Andrew Morton , Alistair Popple , "Kirill A . Shutemov" , Matthew Wilcox Subject: Re: [PATCH RFC v2 1/2] mm: Don't skip swap entry even if zap_details specified Message-ID: References: <20211115134951.85286-1-peterx@redhat.com> <20211115134951.85286-2-peterx@redhat.com> <9937aaa-d9ab-2839-b0b7-691d85c9141@google.com> <391aa58d-ce84-9d4-d68d-d98a9c533255@google.com> MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Rspamd-Queue-Id: 0C82AC0008 X-Stat-Signature: qiecxcmwmxgbm4utgpkcq9z6tfuzfh46 Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=RhmzszAD; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf28.hostedemail.com: domain of peterx@redhat.com has no SPF policy when checking 170.10.129.124) smtp.mailfrom=peterx@redhat.com X-Rspamd-Server: rspam06 X-HE-Tag: 1642741899-764624 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 Fri, Jan 21, 2022 at 11:11:42AM +0800, Peter Xu wrote: > On Thu, Jan 20, 2022 at 06:32:29PM +0800, Peter Xu wrote: > > > Except that here we have no page to check, so it looks like you'll > > > have to change should_zap_page() to deal with this case too, or just > > > check details->check_mapping directly. > > > > Yeah I prefer this, as we don't have the page* pointer anyway. > > > > > Which raises the question again > > > of why I did not just use a boolean flag there originally: aah, I think > > > I've found why. In those days there was a horrible "optimization", for > > > better performance on some benchmark I guess, which when you read from > > > /dev/zero into a private mapping, would map the zero page there (look > > > up read_zero_pagealigned() and zeromap_page_range() if you dare). So > > > there was another category of page to be skipped along with the anon > > > COWs, and I didn't want multiple tests in the zap loop, so checking > > > check_mapping against page->mapping did both. I think nowadays you > > > could do it by checking for PageAnon page (or genuine swap entry) > > > instead. > > > > It must be PageAnon already, isn't it? > > I think I see what you meant now.. > > I assume the special case is gone, how about I switch zap_mappings back into > a boolean altogether in this patchset? Thanks, Oh, one more thing.. When reading the history and also your explanations above, I figured one thing that may not be right for a long time, on zero page handling of zapping. If to quote your comment above, we should keep the zero page entries too if zap_details.zap_mapping is specified. However it's not true for a long time, I guess starting from when vm_normal_page() returns NULL for zero pfns. I also have a very strong feeling that in the old world the "page*" is non-NULL for zero pages here. So... I'm boldly thinking whether we should also need another fix upon the zero page handling here too, probably before this whole patchset (so it'll be the 1st patch, it should directly apply to master) because if I'm right on above it can be seen as another separate bug fix: ---8<--- diff --git a/mm/memory.c b/mm/memory.c index f306e698a1e3..9b8348746e0b 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -1320,11 +1320,18 @@ struct zap_details { static inline bool zap_skip_check_mapping(struct zap_details *details, struct page *page) { - if (!details || !page) + /* No detail pointer or no zap_mapping pointer, zap all */ + if (!details || !details->zap_mapping) return false; - return details->zap_mapping && - (details->zap_mapping != page_rmapping(page)); + /* + * For example, the zero page. If the user wants to keep the private + * pages, zero page should also be in count. + */ + if (!page) + return true; + + return details->zap_mapping != page_rmapping(page); } static unsigned long zap_pte_range(struct mmu_gather *tlb, ---8<--- page can be NULL for e.g. PFNMAP and when error occured too above. I assume we don't need to bother with them (e.g., I don't think PFNMAP or MIXED should specify even_cows=false at all, because there's no page cache layer), though. Mostly it's about how we should handle zero page right. Thanks, -- Peter Xu