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 6DB48C433EF for ; Wed, 13 Apr 2022 09:30:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EC7A36B0072; Wed, 13 Apr 2022 05:30:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E774C6B0073; Wed, 13 Apr 2022 05:30:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D3F996B0074; Wed, 13 Apr 2022 05:30:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.28]) by kanga.kvack.org (Postfix) with ESMTP id C55D06B0072 for ; Wed, 13 Apr 2022 05:30:24 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 89949252DC for ; Wed, 13 Apr 2022 09:30:24 +0000 (UTC) X-FDA: 79351335168.17.1CE2F3A Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf08.hostedemail.com (Postfix) with ESMTP id F3FCD16000E for ; Wed, 13 Apr 2022 09:30:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1649842223; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=sUAWCEtJ7W8Lp2MMf8nQbTxa4Gjk9+/HNaILcWqE2Ig=; b=eleBN7IQOYNwqhzyp8UOTfP934gm8Gd8zrWmM2UKQtts8In4H47RE5PI4D7pXWRFbLRVQ/ lrHjdNldjjBianOZ/MgMjrFCbtrJdM7dMtX4pzVs8Z/xSP5XI2WBw5h5RzQMA88B4KZFOS PCMgiuD6AZswUKdSIZXo00YuNdC9tGg= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-607-2ByMTfZ5OP6PNHRLE_WdPQ-1; Wed, 13 Apr 2022 05:30:22 -0400 X-MC-Unique: 2ByMTfZ5OP6PNHRLE_WdPQ-1 Received: by mail-wm1-f72.google.com with SMTP id j20-20020a05600c1c1400b0038eb5cb35ecso2576284wms.9 for ; Wed, 13 Apr 2022 02:30:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:cc:references:from:organization:subject :in-reply-to:content-transfer-encoding; bh=sUAWCEtJ7W8Lp2MMf8nQbTxa4Gjk9+/HNaILcWqE2Ig=; b=ligaSzZmr2bIqvgiHzCJvNQQ8ec4ruK9SlETkH5th+llCSP3CaDICB3EJAK1e2hAgN joNsgOZ80zLXzNeE7l122Ht1syVHT2KaAq9+9yGbn0K5yXIV7FKrPjP4A+sqZ/oYemES YSgMS7/W0Se8h1LPfAZSe+UzdzsnZ68wRpWpwU4DsoPNpBn40hXwWdddp7vlWEJCTek+ kZDO+AZHE33AgZsej2PtYn2N0toEhA/fpQyyB1AebU0pexEH5nJFaAYqnd2R8qbMwy3s Nk0tpgDNBMbPNDH+9P5q6jgR1zKCM+DJ9h9j5OzIV67n7qmJE+1/qmTb/7EPE3ATXiv0 /BFw== X-Gm-Message-State: AOAM531QNFnkQYKpIC6xu4tDrbpKpYnemHk3XW1lYGBxmsnTikUB32PM 0QYJl+EcKpn+YVkGD3NF4Lgsx/MN0wiydhkEybh0JjEhKSA26AqZWwzomTlcrie+ef0JjqKWNhK k8OlfUahTJz4= X-Received: by 2002:a05:600c:3ac7:b0:38e:c6ef:ff0 with SMTP id d7-20020a05600c3ac700b0038ec6ef0ff0mr7356602wms.8.1649842220992; Wed, 13 Apr 2022 02:30:20 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyd3XaLEhPCG4J24HCG8pKWKl8usohh+7J5bIP+p03v6bOndnNfB1jN1ExM+RVo0C4IS9g7NA== X-Received: by 2002:a05:600c:3ac7:b0:38e:c6ef:ff0 with SMTP id d7-20020a05600c3ac700b0038ec6ef0ff0mr7356584wms.8.1649842220717; Wed, 13 Apr 2022 02:30:20 -0700 (PDT) Received: from ?IPV6:2003:cb:c704:5800:1078:ebb9:e2c3:ea8c? (p200300cbc70458001078ebb9e2c3ea8c.dip0.t-ipconnect.de. [2003:cb:c704:5800:1078:ebb9:e2c3:ea8c]) by smtp.gmail.com with ESMTPSA id i4-20020a05600c354400b0038e9c5924d6sm1958059wmq.29.2022.04.13.02.30.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 13 Apr 2022 02:30:20 -0700 (PDT) Message-ID: <374d2be1-e13d-e605-ff80-b9d5eee4c40e@redhat.com> Date: Wed, 13 Apr 2022 11:30:19 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.6.2 To: Miaohe Lin Cc: linux-kernel , Linux-MM References: <20220329164329.208407-1-david@redhat.com> <20220329164329.208407-2-david@redhat.com> <28142e3e-2556-0ca2-7ac5-7420ef862259@huawei.com> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH v2 1/8] mm/swap: remember PG_anon_exclusive via a swp pte bit In-Reply-To: <28142e3e-2556-0ca2-7ac5-7420ef862259@huawei.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: o75zf75d5fuetwpynofzsp95qk5nj4fz Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=eleBN7IQ; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf08.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.129.124) smtp.mailfrom=david@redhat.com X-Rspamd-Queue-Id: F3FCD16000E X-HE-Tag: 1649842223-23564 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 13.04.22 10:58, Miaohe Lin wrote: > On 2022/3/30 0:43, David Hildenbrand wrote: >> Currently, we clear PG_anon_exclusive in try_to_unmap() and forget about > ... >> diff --git a/mm/memory.c b/mm/memory.c >> index 14618f446139..9060cc7f2123 100644 >> --- a/mm/memory.c >> +++ b/mm/memory.c >> @@ -792,6 +792,11 @@ copy_nonpresent_pte(struct mm_struct *dst_mm, struct mm_struct *src_mm, >> &src_mm->mmlist); >> spin_unlock(&mmlist_lock); >> } >> + /* Mark the swap entry as shared. */ >> + if (pte_swp_exclusive(*src_pte)) { >> + pte = pte_swp_clear_exclusive(*src_pte); >> + set_pte_at(src_mm, addr, src_pte, pte); >> + } >> rss[MM_SWAPENTS]++; >> } else if (is_migration_entry(entry)) { >> page = pfn_swap_entry_to_page(entry); >> @@ -3559,6 +3564,7 @@ vm_fault_t do_swap_page(struct vm_fault *vmf) >> struct page *page = NULL, *swapcache; >> struct swap_info_struct *si = NULL; >> rmap_t rmap_flags = RMAP_NONE; >> + bool exclusive = false; >> swp_entry_t entry; >> pte_t pte; >> int locked; >> @@ -3724,6 +3730,46 @@ vm_fault_t do_swap_page(struct vm_fault *vmf) >> BUG_ON(!PageAnon(page) && PageMappedToDisk(page)); >> BUG_ON(PageAnon(page) && PageAnonExclusive(page)); >> >> + /* >> + * Check under PT lock (to protect against concurrent fork() sharing >> + * the swap entry concurrently) for certainly exclusive pages. >> + */ >> + if (!PageKsm(page)) { >> + /* >> + * Note that pte_swp_exclusive() == false for architectures >> + * without __HAVE_ARCH_PTE_SWP_EXCLUSIVE. >> + */ >> + exclusive = pte_swp_exclusive(vmf->orig_pte); >> + if (page != swapcache) { >> + /* >> + * We have a fresh page that is not exposed to the >> + * swapcache -> certainly exclusive. >> + */ >> + exclusive = true; >> + } else if (exclusive && PageWriteback(page) && >> + !(swp_swap_info(entry)->flags & SWP_STABLE_WRITES)) { > > Really sorry for late respond and a newbie question. IIUC, if SWP_STABLE_WRITES is set, > it means concurrent page modifications while under writeback is not supported. For these > problematic swap backends, exclusive marker is dropped. So the above if statement is to > filter out these problematic swap backends which have SWP_STABLE_WRITES set. If so, the > above check should be && (swp_swap_info(entry)->flags & SWP_STABLE_WRITES)), i.e. no "!". > Or am I miss something? Oh, thanks for your careful eyes! Indeed, SWP_STABLE_WRITES indicates that the backend *requires* stable writes, meaning, we must not modify the page while writeback is active. So if and only if that is set, we must drop the exclusive marker. This essentially corresponds to previous reuse_swap_page() logic: bool reuse_swap_page(struct page *page) { ... if (!PageWriteback(page)) { ... } else { ... if (p->flags & SWP_STABLE_WRITES) { spin_unlock(&p->lock); return false; } ... } Fortunately, this only affects such backends. For backends without SWP_STABLE_WRITES, the current code is simply sub-optimal. So yes, this has to be } else if (exclusive && PageWriteback(page) && (swp_swap_info(entry)->flags & SWP_STABLE_WRITES)) { Let me try finding a way to test this, the tests I was running so far were apparently not using a backend with SWP_STABLE_WRITES. -- Thanks, David / dhildenb