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 0B4E2C433F5 for ; Thu, 20 Jan 2022 17:49:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 91CAB6B009F; Thu, 20 Jan 2022 12:49:29 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8CB1E6B00A1; Thu, 20 Jan 2022 12:49:29 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 746016B00A2; Thu, 20 Jan 2022 12:49:29 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0223.hostedemail.com [216.40.44.223]) by kanga.kvack.org (Postfix) with ESMTP id 6613A6B009F for ; Thu, 20 Jan 2022 12:49:29 -0500 (EST) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 2518E944DF for ; Thu, 20 Jan 2022 17:49:29 +0000 (UTC) X-FDA: 79051402458.25.C8C69E0 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf04.hostedemail.com (Postfix) with ESMTP id A3A224000F for ; Thu, 20 Jan 2022 17:49:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1642700968; 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=nCG2sPJLK6kzXhJ8UHVqsNF/fPPpVfwzYVA6Udq3IAs=; b=Z+Xg7M3ZOEFRwbQQc+nwtZ86mDiREMFXUp5YKkXGg1y5zcuofmuJutsIviQOYYpBK+zKQH gWGFxN9A3RD0jqeDkr+D3yIWDIvUCDlvBI+VjjcKLtOuHcg8M4uZuQb5hdkVxY8noa4kNq vxJUS6N4Zd1Fkiemt/te9oGIoy6h9oo= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-594-cZ9vTnY3NrSaJPd6xZs4dg-1; Thu, 20 Jan 2022 12:49:26 -0500 X-MC-Unique: cZ9vTnY3NrSaJPd6xZs4dg-1 Received: by mail-wm1-f70.google.com with SMTP id i26-20020a1c541a000000b0034dc8bd7078so2823473wmb.8 for ; Thu, 20 Jan 2022 09:49:26 -0800 (PST) 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=nCG2sPJLK6kzXhJ8UHVqsNF/fPPpVfwzYVA6Udq3IAs=; b=FCJ3BMOIv2iJZpfZvhgiCgsJqsUzSMJVP32lkXbBrhCuH9qAIy5EvLFj8hG0o7ZEZG vEj4sKO/VVaiNEkEDPf/1IWYrcfFQhFmuhIbjyw7i9jiZeal5LonYjfyieTUeWJwPwr+ czMV9R2YY5JAc0EEXXdfd9Fr0nORNNtEneA6xRc3RGB/ZJfc9KdU/WTgqmghmI0HTYUL pMqRD4v1JEC7nQLvVUuV3Jw8vbGE3hd0Noqn5iLfbfgbTZTkeqhS+OlPj6XWkPuYO1xG 5Y4aoFXb1d8v4aXJJvzAAbqBKp/pio7p/s9H4fgrovXir4P3hetzsy/p6Tt6QqPm0OWt aTYw== X-Gm-Message-State: AOAM532g4bzkti3RexcRzc81l3rtNrRXT3aaMihFRMJfz50dnLk+jmNb Chvi4mUsB9mYeKaubwy38gMjo2ssidIP0baB3aeh2QLxkWjGE1sfFxxFu50I2IHEY+TWz/J4Jjd OVUKKIzNUJIg= X-Received: by 2002:a7b:c389:: with SMTP id s9mr10063580wmj.187.1642700965659; Thu, 20 Jan 2022 09:49:25 -0800 (PST) X-Google-Smtp-Source: ABdhPJwOgrAzOzVk/Tex+x+IQgm2nyqsRrltPt6JVBIbhqjWR5Q/MBuyoXyZStU3JqtYqk+plHRdxw== X-Received: by 2002:a7b:c389:: with SMTP id s9mr10063554wmj.187.1642700965427; Thu, 20 Jan 2022 09:49:25 -0800 (PST) Received: from ?IPV6:2003:cb:c70e:5800:eeb:dae2:b1c0:f5d1? (p200300cbc70e58000eebdae2b1c0f5d1.dip0.t-ipconnect.de. [2003:cb:c70e:5800:eeb:dae2:b1c0:f5d1]) by smtp.gmail.com with ESMTPSA id w22sm3554602wra.59.2022.01.20.09.49.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 20 Jan 2022 09:49:24 -0800 (PST) Message-ID: <605bff5f-1244-af8f-bb2a-c1da0fc4bf7a@redhat.com> Date: Thu, 20 Jan 2022 18:49:24 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 To: Linus Torvalds Cc: Matthew Wilcox , "zhangliang (AG)" , Andrew Morton , Linux-MM , Linux Kernel Mailing List , wangzhigang17@huawei.com References: <20220113140318.11117-1-zhangliang5@huawei.com> <172ccfbb-7e24-db21-7d84-8c8d8c3805fd@redhat.com> <9cd7eee2-91fd-ddb8-e47d-e8585e5baa05@redhat.com> <747ff31c-6c9e-df6c-f14d-c43aa1c77b4a@redhat.com> <43e41259-b228-2a75-e59d-0c6a1e81912f@redhat.com> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH] mm: reuse the unshared swapcache page in do_wp_page In-Reply-To: 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-Queue-Id: A3A224000F X-Stat-Signature: 4ps1gbhdbdd9zn9pkuay8x7k1k5h95xp Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=Z+Xg7M3Z; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf04.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=david@redhat.com X-Rspamd-Server: rspam03 X-HE-Tag: 1642700968-404837 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 20.01.22 18:22, Linus Torvalds wrote: > On Thu, Jan 20, 2022 at 5:46 PM David Hildenbrand wrote: >> >> I'm, not concerned about fork(), I'm concerned about other false positives. > > Without a fork(), you won't have the THP marked for COW, so is it > really an issue? Oh sorry, I should have been clearer. I absolutely agree that there is no way around COW if there are multiple sharers of a page :) If you fork() and write to a shared page, you have to expect that THP get split and that you get a copy. No change on that front. At this point I'm trying to assess the impact of the change and how to eventually mitigate it if it turns out to be a real problem. (I've been spending a lot of time trying to understand all the complexity, and sometimes my brain is ... a bit overloaded by all of that. Well, at least I learn a lot ...) One scenario I have in mind how we can end up easily with R/O mapped exclusive THP is a simple fork() with an immediate exec(), unmap() or exit() of the child. Might not be the most efficient way of doing things, but that doesn't mean that existing user space doesn't rely on it not happening. Then, of course, there are other ways to read-protect THP temporarily (mprotect() and friends), where you wouldn't expect to lose your THP, but it's somewhat a secondary concern most probably . Obviously, we need another (temporary/speculative) reference on the THP or writeback to actually split it. I'm *hoping* that it will be so rare that we really don't care. I decided to always lock the THP in do_wp_page() to at least handle page migration and swapcache more reliably. To answer you question: people optimized the reuse case heavily previously (reuse_swap_page()), and I can see how it might happen. I'm hoping that it won't matter in practice, but I'd like to at least document the impact and have some magic solution in sleeve that I can just pull out when reports start coming in. > >> Here is what I currently have, I hope that makes sense: > > From a quick look, that patch looks fine to me, but there might be > something I'm missing... And who knows what odd usage patterns there > might be in this area. The whole odd Android thing with forking that > zygote process. Exactly my thoughts. I'm trying to be very careful. -- Thanks, David / dhildenb