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=-5.1 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,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 BD828C6377A for ; Mon, 19 Jul 2021 07:34:29 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4181460E0B for ; Mon, 19 Jul 2021 07:34:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4181460E0B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id C0E748D00F6; Mon, 19 Jul 2021 03:34:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BBF0A8D00EC; Mon, 19 Jul 2021 03:34:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A39768D00F6; Mon, 19 Jul 2021 03:34:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0157.hostedemail.com [216.40.44.157]) by kanga.kvack.org (Postfix) with ESMTP id 7CBF08D00EC for ; Mon, 19 Jul 2021 03:34:29 -0400 (EDT) Received: from smtpin36.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 18B0122AB9 for ; Mon, 19 Jul 2021 07:34:28 +0000 (UTC) X-FDA: 78378524616.36.3870DF2 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf08.hostedemail.com (Postfix) with ESMTP id A31DE30000A0 for ; Mon, 19 Jul 2021 07:34:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1626680066; 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=0sfSO6C1l3WtCtuFbg0VI6VLBjRIkRSfgQNpDtonfxE=; b=ex0hjrB2/f7Ut+sovzfD7zya630LQEw9yIWf3iPicmFXM1YsC7zlV5EhkdKBzqRzIzfiqq UKyzVswO9IU0fuai0dvH3au9RNIuWetuxYypNMRH8caQH73uuvRQLt+Oy/74gVV5N59RMe vizG9F+44GsJ27llhkX/1mjCeNHpF/A= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-187-_H3LyfJNPZq-1RjNTEvIuQ-1; Mon, 19 Jul 2021 03:34:23 -0400 X-MC-Unique: _H3LyfJNPZq-1RjNTEvIuQ-1 Received: by mail-wr1-f72.google.com with SMTP id d9-20020adffbc90000b029011a3b249b10so8304922wrs.3 for ; Mon, 19 Jul 2021 00:34:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:references:from:organization:subject :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=0sfSO6C1l3WtCtuFbg0VI6VLBjRIkRSfgQNpDtonfxE=; b=sRnACzp708f1tZeZOiuSc1W6G7qzhK6GOCe8zJxnicSe00FlRil4/KNyyg2eDRLnBW so3sFSHwQxr378PFhefFW8IxEc3uRY5tOpc+EjsAY5OdJKzoWRlYb8GHl0URV0uZjdku IBpAf1oE56tUUFNCq021w3llmhxKsm3eEsOzxaKNx1yZWWeb+Qt+reacH3uy6BFmOXwQ a3cmnSAA2YQb/cUFCEieGI+0Tv/kO3zf3aip+jCZjoCebEEk/ThpRYiIO1NE3I/pMn5b 85ANNtH1c1RFNJ6F76fE+50UiUe1xUPkXiQ0pSE+qxlxpuJJW6bg9/pQ3tSvWqaEbzKS yaBg== X-Gm-Message-State: AOAM532DmO79RjqnDel4olR6DG9LBhbPAc7QBrGm5DzKGLvyFefoOGG2 /unjsei9BCX9iEAcUAa28WQlVTptmScFK22efLOE1RxgpLZ8mpa3tkIVZ7liD8JROPxiBdCyXJ7 UhsjrstFA5O8= X-Received: by 2002:a05:600c:3595:: with SMTP id p21mr17863841wmq.105.1626680062036; Mon, 19 Jul 2021 00:34:22 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz07efcFEv5EX0OoyTVlUJhLNO1Fd9o7f8O9ViBtmkhlottvR3Rzu2ykVMUwwmu3TH+CIaAhw== X-Received: by 2002:a05:600c:3595:: with SMTP id p21mr17863820wmq.105.1626680061792; Mon, 19 Jul 2021 00:34:21 -0700 (PDT) Received: from ?IPv6:2003:d8:2f0a:7f00:fad7:3bc9:69d:31f? (p200300d82f0a7f00fad73bc9069d031f.dip0.t-ipconnect.de. [2003:d8:2f0a:7f00:fad7:3bc9:69d:31f]) by smtp.gmail.com with ESMTPSA id y3sm19433446wrh.16.2021.07.19.00.34.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 19 Jul 2021 00:34:21 -0700 (PDT) To: Qi Zheng , akpm@linux-foundation.org, tglx@linutronix.de, hannes@cmpxchg.org, mhocko@kernel.org, vdavydov.dev@gmail.com Cc: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, songmuchun@bytedance.com References: <20210718043034.76431-1-zhengqi.arch@bytedance.com> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH 0/7] Free user PTE page table pages Message-ID: <5ce5fb25-df1d-b807-8807-595b8a7bfc63@redhat.com> Date: Mon, 19 Jul 2021 09:34:20 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <20210718043034.76431-1-zhengqi.arch@bytedance.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: A31DE30000A0 X-Stat-Signature: r7khxrsk1iufnxy3ihtm8xx19dwrr675 Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=ex0hjrB2; spf=none (imf08.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 216.205.24.124) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-HE-Tag: 1626680067-738762 Content-Transfer-Encoding: quoted-printable 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 18.07.21 06:30, Qi Zheng wrote: > Hi, >=20 > This patch series aims to free user PTE page table pages when all PTE e= ntries > are empty. >=20 > The beginning of this story is that some malloc libraries(e.g. jemalloc= or > tcmalloc) usually allocate the amount of VAs by mmap() and do not unmap= those VAs. > They will use madvise(MADV_DONTNEED) to free physical memory if they wa= nt. > But the page tables do not be freed by madvise(), so it can produce man= y > page tables when the process touches an enormous virtual address space. ... did you see that I am actually looking into this? https://lkml.kernel.org/r/bae8b967-c206-819d-774c-f57b94c4b362@redhat.com and have already spent a significant time on it as part of my research,=20 which is *really* unfortunate and makes me quite frustrated at the=20 beginning of the week alreadty ... Ripping out page tables is quite difficult, as we have to stop all page=20 table walkers from touching it, including the fast_gup, rmap and page=20 faults. This usually involves taking the mmap lock in write. My approach=20 does page table reclaim asynchronously from another thread and do not=20 rely on reference counts. --=20 Thanks, David / dhildenb