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=-6.9 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 AD612C433F5 for ; Wed, 15 Sep 2021 14:52:51 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2D8D061108 for ; Wed, 15 Sep 2021 14:52:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 2D8D061108 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=bytedance.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 719F8900002; Wed, 15 Sep 2021 10:52:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6A2956B0072; Wed, 15 Sep 2021 10:52:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5470D900002; Wed, 15 Sep 2021 10:52:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0096.hostedemail.com [216.40.44.96]) by kanga.kvack.org (Postfix) with ESMTP id 3FDB26B0071 for ; Wed, 15 Sep 2021 10:52:50 -0400 (EDT) Received: from smtpin32.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id B70088249980 for ; Wed, 15 Sep 2021 14:52:49 +0000 (UTC) X-FDA: 78590099658.32.2045BBE Received: from mail-pj1-f49.google.com (mail-pj1-f49.google.com [209.85.216.49]) by imf17.hostedemail.com (Postfix) with ESMTP id D1903F00038D for ; Wed, 15 Sep 2021 14:52:47 +0000 (UTC) Received: by mail-pj1-f49.google.com with SMTP id v19so2326983pjh.2 for ; Wed, 15 Sep 2021 07:52:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=C2Pv2ooTfdce7tXkTH8ROpCuvqDgdiR8s/9mMjPOHH4=; b=dcxJIWqlAzb5DYTIYG8AwlXIJweAuseXT6s6HKLdu5Mso6GT3PxeeDVzZEBwDe3QPx hv5Le8wmx3cu5sEv8OmHm7HNZkoVplar0UGIB/u/munG/AYe3w/nqfzXpejeVPCswqeU tfcF/S7wumQ2gzp8dF4CBzqA44VbIKwQjhVACCFjyVwxiUH0B5DD2Xu4BAB05bPu9Iet 6dlQsN9bgjJ5w3TRcqfCOwny6iODsYmDtWsf0/tUXI7t0XlzL/tPjg1lXrv8AFfyImZE fiA0sQdsPGJZUkZmNKeyRJIw5/lwpQ/qVBReNAij12Qcm5XngiCXJCocg5uTfOU4qION 3ztg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=C2Pv2ooTfdce7tXkTH8ROpCuvqDgdiR8s/9mMjPOHH4=; b=qmZmeANqLjlWLs9ng3G7xuIdufre9P7g31kE1ADbZngqiYugV994qv82qDI366HHua RMkPmJmUhk8TxOWx/fWQvszvATQt68rik5ej5FfwnntMC8aGx3CK4SgsrT2W+WDi/Rds kJlzUq8bq6SEtHfMcQLdQpfN4eFTYhMbpZ/3QhZtXjCtFklnUh9YmozbxSGqY9i32Dae 4CwrBgzqVtGOUCogZAKx/xObSUhkkzvZxg64VAJrf/AHKpcU2T5xV+RokkfbZaxEeB55 xcNTCn67alrjZbvSSdK808RRz72GGT2wzvb4BDo25R4grPqkiP+HPGE/YvGxJCxu5dji q/sA== X-Gm-Message-State: AOAM531bh6CH9xgNi0+cFCO5AvssBhHCFV1yxZagA5Z0ARHOmjwkwoZI 1waLHp6GVYP5vdIHAsA21wU6HQ== X-Google-Smtp-Source: ABdhPJwSZ7CGy9apdu4GbVHSFYzv1SRtVFZ1FNwd4u1nYPQGpLKeKoeqfN08ZNJIqTPyJgbdGYhXsg== X-Received: by 2002:a17:90a:428f:: with SMTP id p15mr9138753pjg.75.1631717566490; Wed, 15 Sep 2021 07:52:46 -0700 (PDT) Received: from [10.254.148.129] ([139.177.225.252]) by smtp.gmail.com with ESMTPSA id b10sm198777pfl.220.2021.09.15.07.52.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 15 Sep 2021 07:52:45 -0700 (PDT) Subject: Re: [PATCH v2 0/9] Free user PTE page table pages To: David Hildenbrand , akpm@linux-foundation.org, tglx@linutronix.de, hannes@cmpxchg.org, mhocko@kernel.org, vdavydov.dev@gmail.com, kirill.shutemov@linux.intel.com, mika.penttila@nextfour.com Cc: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, songmuchun@bytedance.com References: <20210819031858.98043-1-zhengqi.arch@bytedance.com> <5b9348fc-95fe-5be2-e9df-7c906e0c9b81@redhat.com> From: Qi Zheng Message-ID: <41ceeec1-52c4-4e99-201c-e1e05b2afbbc@bytedance.com> Date: Wed, 15 Sep 2021 22:52:40 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <5b9348fc-95fe-5be2-e9df-7c906e0c9b81@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: D1903F00038D X-Stat-Signature: 4rdaqowxcycf5h4cfrzhw1ntm4endeo8 Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=bytedance-com.20150623.gappssmtp.com header.s=20150623 header.b=dcxJIWql; spf=pass (imf17.hostedemail.com: domain of zhengqi.arch@bytedance.com designates 209.85.216.49 as permitted sender) smtp.mailfrom=zhengqi.arch@bytedance.com; dmarc=pass (policy=none) header.from=bytedance.com X-HE-Tag: 1631717567-767866 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 9/1/21 8:32 PM, David Hildenbrand wrote: Hi David, >> > > > Some high-level feedback after studying the code: > > 1. Try introducing the new dummy primitives ("API") first, and then > convert each subsystem individually; especially, maybe convert the whole > pagefault handling in a single patch, because it's far from trivial. > This will make this series much easier to digest. I am going to split this patch series as follows: 1. Introduce the new dummy APIs, which is an empty implementation. But I will explain its semantics. 2. Merge #6, #7 and #8, and call these dummy APIs in any necessary location, and split some special cases into single patches, such as pagefault and gup, etc. So that we can explain in more detail the concurrency in these cases. For example, we don't need to hold any pte_refcount in the fast path in gup on the x86_64 platform. Because the PTE page can't be freed after the local CPU interrupt is closed in the fast path in gup. 3. Introduce CONFIG_FREE_USER_PTE and implement these empty dummy APIs. 4. Add a description document. And I try to add a function that combines pte_offset_map() and pte_try_get(). Maybe the func name is pte_try_map() recommended by Jason, or keep the pte_offset_map() unchanged? > > Then, have a patch that adds actual logic to the dummy primitives via a > config option. > > 2. Minimize the API. > > a) pte_alloc_get{,_map,_map_lock}() is really ugly. Maybe restrict it to > pte_alloc_get() I also think pte_alloc_get{,_map,_map_lock}() is ugly, but I can't figure out a more suitable name. Maybe we can keep the pte_alloc{,_map,_map_lock}() without any modification? But I am worried that the caller will forget to call the paired pte_put(). > > b) pmd_trans_unstable_or_pte_try_get() and friends are really ugly. > > Handle it independently for now, even if it implies duplicate runtime > checks. > > if (pmd_trans_unstable() || !pte_try_get()) ... > > We can always optimize later, once we can come up with something cleaner. > > 3. Merge #6, and #7, after factoring out all changes to other subsystems > to use the API > > 4. Merge #8 into #6. There is a lot of unnecessary code churn back and > forth, and IMHO the whole approach might not make sense without RCU due > to the additional locking overhead. > > Or at least, try to not modify the API you introduced in patch #6 or #7 > in #8 again. Converting all call sites back and forth just makes review > quite hard. > > > I am preparing some some cleanups that will make get_locked_pte() and > similar a little nicer to handle. I'll send them out this or next week. > Thanks, Qi