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=-2.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 2F6E4C4332F for ; Sat, 18 Sep 2021 11:02:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0C77E61212 for ; Sat, 18 Sep 2021 11:02:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238862AbhIRLDX (ORCPT ); Sat, 18 Sep 2021 07:03:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55924 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238803AbhIRLDW (ORCPT ); Sat, 18 Sep 2021 07:03:22 -0400 Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C5CF8C061574; Sat, 18 Sep 2021 04:01:58 -0700 (PDT) Received: by mail-ed1-x52e.google.com with SMTP id q3so40037593edt.5; Sat, 18 Sep 2021 04:01:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tgwWxXw9qWF2mVmQmH8HomBdLaqa+aeD+D207S0R8ng=; b=lN6I6aPUKmTKLDI68h3zBHjMSSGs872bSN081mM5Hgxr9QKqBGUbcbrvl1T8xbqNrE No0TnssdKr0M12kaVlsMUlSn1Ejf583f9lzeCVudQ37+pOtA3vuiw0J3afTyEx+NSZg0 YVybYMTtQNkjXHBMokgfidQnvbjHIN9rHgHBdjeEJWHTjd5mNZaBQh5MFnEmExLxqj8D qgHq2fFREKQBI9jtGlPTlbP2sLfa1Duzo+8bv1q67U2yfmIe92XnMGvjraxTRJTQBUD0 PeyVpGGhGNWkq8Yn2htEHAa1syQ9LyiH/KWgT9QXxTv5N880wvo3EOLDnWuHiXmDwCwR aKkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tgwWxXw9qWF2mVmQmH8HomBdLaqa+aeD+D207S0R8ng=; b=npSsgFWPilyrVUwI9bgCHcJ6siuiaUBmoT9SAhH2I4twPhL0Vdk0+glVMjgDEY8+QN nlFSZT6JimnvQsMiQWFw143vmxJ7Wf84c/nAe+QT8bhO+aLLRVVmiPfvEQ6bAmHciVNo vUPLsiM3PjvO2F6ulMYoiQ6/S+PHq24wTzdLxSRwLzLmykviMBf2exEleKVGvgSWZQuC HcnoUASCy6MQSfNpZkvA1/c9tc8ZG+tQ5d9BYW3vlUa7xbjX5FZNYlT+7VQnf8FwhYow U1QglJqQr5aLJDznjT1i5GMljGKKnC4KVy9E64HghY7Spel1jsT0oMp734W+H6BdCvRS I9cg== X-Gm-Message-State: AOAM530Hg8qmcjh16DDbnK/BeQjNv32dmhHRe/zU++/T5JKZc7m8aAGQ CEKFBW9/7Zwm7G80T8s6YxLxjInohCN3u4fRvsM= X-Google-Smtp-Source: ABdhPJxjPMJGz7fysVmvyYs/Qt49TE0aDl7xo4okt8Q49xuOgw86nnNYix5jG4r11bj/73Ba0CidOtG9WTvEsezTgpE= X-Received: by 2002:a17:907:75ed:: with SMTP id jz13mr17217421ejc.506.1631962917396; Sat, 18 Sep 2021 04:01:57 -0700 (PDT) MIME-Version: 1.0 References: <20210917034815.80264-1-songmuchun@bytedance.com> <20210917034815.80264-4-songmuchun@bytedance.com> In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Sat, 18 Sep 2021 23:01:46 +1200 Message-ID: Subject: Re: [PATCH RESEND v2 3/4] mm: sparsemem: use page table lock to protect kernel pmd operations To: Muchun Song Cc: Mike Kravetz , Andrew Morton , Oscar Salvador , Michal Hocko , Barry Song , David Hildenbrand , Chen Huang , "Bodeddula, Balasubramaniam" , Jonathan Corbet , Matthew Wilcox , Xiongchun duan , fam.zheng@bytedance.com, Muchun Song , Qi Zheng , linux-doc@vger.kernel.org, LKML , Linux-MM Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Sep 18, 2021 at 10:51 PM Muchun Song wrote: > > On Sat, Sep 18, 2021 at 1:07 PM Barry Song <21cnbao@gmail.com> wrote: > > > > On Sat, Sep 18, 2021 at 12:09 AM Muchun Song wrote: > > > > > > The init_mm.page_table_lock is used to protect kernel page tables, we > > > can use it to serialize splitting vmemmap PMD mappings instead of mmap > > > write lock, which can increase the concurrency of vmemmap_remap_free(). > > > > > > > Curious what is the actual benefit we get in user scenarios from this patch, > > 1. we set bootargs to reserve hugetlb statically > > 2. we "echo" some figures to sys or proc. > > > > In other words, Who is going to care about this concurrency? > > Actually, It increase the concurrency between allocations of > HugeTLB pages. But it is not my first consideration. There are > a lot of users of mmap read lock of init_mm. The mmap write > lock is holding through vmemmap_remap_free(), I want to make > it does not affect other users of mmap read lock. generically makes sense. I guess it wouldn't be critical at all for hugetlb allocation as practically we are not going to reserve and release hugtlb often as they are not THP. anyway, it is not making anything worse and always a win to move. > > I suppose a lot of developers are trying to avoid using mmap write > lock. I am also one of them. > > > Can we have some details on this to put in the commit log? > > For sure. Those judgments above should be placed in the > commit log. > > Thanks. Thanks barry 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=-2.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 2BE0DC433FE for ; Sat, 18 Sep 2021 11:02:01 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id BF30A6101C for ; Sat, 18 Sep 2021 11:02:00 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org BF30A6101C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 5A9D1900002; Sat, 18 Sep 2021 07:02:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 532B96B0072; Sat, 18 Sep 2021 07:02:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3FA7B900002; Sat, 18 Sep 2021 07:02:00 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0121.hostedemail.com [216.40.44.121]) by kanga.kvack.org (Postfix) with ESMTP id 30DA26B0071 for ; Sat, 18 Sep 2021 07:02:00 -0400 (EDT) Received: from smtpin20.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id E067430C70 for ; Sat, 18 Sep 2021 11:01:58 +0000 (UTC) X-FDA: 78600404316.20.2E32C6B Received: from mail-ed1-f48.google.com (mail-ed1-f48.google.com [209.85.208.48]) by imf30.hostedemail.com (Postfix) with ESMTP id A8ACDE00198F for ; Sat, 18 Sep 2021 11:01:58 +0000 (UTC) Received: by mail-ed1-f48.google.com with SMTP id v5so39514378edc.2 for ; Sat, 18 Sep 2021 04:01:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tgwWxXw9qWF2mVmQmH8HomBdLaqa+aeD+D207S0R8ng=; b=lN6I6aPUKmTKLDI68h3zBHjMSSGs872bSN081mM5Hgxr9QKqBGUbcbrvl1T8xbqNrE No0TnssdKr0M12kaVlsMUlSn1Ejf583f9lzeCVudQ37+pOtA3vuiw0J3afTyEx+NSZg0 YVybYMTtQNkjXHBMokgfidQnvbjHIN9rHgHBdjeEJWHTjd5mNZaBQh5MFnEmExLxqj8D qgHq2fFREKQBI9jtGlPTlbP2sLfa1Duzo+8bv1q67U2yfmIe92XnMGvjraxTRJTQBUD0 PeyVpGGhGNWkq8Yn2htEHAa1syQ9LyiH/KWgT9QXxTv5N880wvo3EOLDnWuHiXmDwCwR aKkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tgwWxXw9qWF2mVmQmH8HomBdLaqa+aeD+D207S0R8ng=; b=hBcpsk5vGh3PcNfgfwiF63LTw0HnrqEZXhMvdEND1G66LyrER8OcWe5N3Rj4aMrkKk gj8aBk02ubeNbggO/IYlT4jzVCrU5txgsN25nl6Dgu/qcVjCZEEZLisdsadSLrVW9HI7 7NMe/fE4hBweWsOvsflwo5s5drz5L3S0YCh+7UQ2WFjMI64HCdODd0IQUZ2i4lM9SjL1 fuOtVnWdhCv73+7S8+fEIfCyblIXGIn0h70AIKL1B8COy0kRV711whFtCD7ghdF0GHuM T5wu5UuJijr+nGW5A8FcIvN4RslRLMKSB0JW/Zp/N+r2bIHP0TnkSU+S5/dh1eJYMFAR EB8A== X-Gm-Message-State: AOAM530abskGO6syclwIU7bJAFDfZr5ZzYd2gBwHk4ypqwLtZDwAb25y HzyHiWzEFDd6EysLmyPV6+Vxp7rwo4XjO3Q3qgs= X-Google-Smtp-Source: ABdhPJxjPMJGz7fysVmvyYs/Qt49TE0aDl7xo4okt8Q49xuOgw86nnNYix5jG4r11bj/73Ba0CidOtG9WTvEsezTgpE= X-Received: by 2002:a17:907:75ed:: with SMTP id jz13mr17217421ejc.506.1631962917396; Sat, 18 Sep 2021 04:01:57 -0700 (PDT) MIME-Version: 1.0 References: <20210917034815.80264-1-songmuchun@bytedance.com> <20210917034815.80264-4-songmuchun@bytedance.com> In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Sat, 18 Sep 2021 23:01:46 +1200 Message-ID: Subject: Re: [PATCH RESEND v2 3/4] mm: sparsemem: use page table lock to protect kernel pmd operations To: Muchun Song Cc: Mike Kravetz , Andrew Morton , Oscar Salvador , Michal Hocko , Barry Song , David Hildenbrand , Chen Huang , "Bodeddula, Balasubramaniam" , Jonathan Corbet , Matthew Wilcox , Xiongchun duan , fam.zheng@bytedance.com, Muchun Song , Qi Zheng , linux-doc@vger.kernel.org, LKML , Linux-MM Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: A8ACDE00198F X-Stat-Signature: r71rn4ihyrxhoek3x6stxcktdq97aje8 Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=lN6I6aPU; spf=pass (imf30.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.208.48 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-HE-Tag: 1631962918-226675 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 Sat, Sep 18, 2021 at 10:51 PM Muchun Song wrote: > > On Sat, Sep 18, 2021 at 1:07 PM Barry Song <21cnbao@gmail.com> wrote: > > > > On Sat, Sep 18, 2021 at 12:09 AM Muchun Song wrote: > > > > > > The init_mm.page_table_lock is used to protect kernel page tables, we > > > can use it to serialize splitting vmemmap PMD mappings instead of mmap > > > write lock, which can increase the concurrency of vmemmap_remap_free(). > > > > > > > Curious what is the actual benefit we get in user scenarios from this patch, > > 1. we set bootargs to reserve hugetlb statically > > 2. we "echo" some figures to sys or proc. > > > > In other words, Who is going to care about this concurrency? > > Actually, It increase the concurrency between allocations of > HugeTLB pages. But it is not my first consideration. There are > a lot of users of mmap read lock of init_mm. The mmap write > lock is holding through vmemmap_remap_free(), I want to make > it does not affect other users of mmap read lock. generically makes sense. I guess it wouldn't be critical at all for hugetlb allocation as practically we are not going to reserve and release hugtlb often as they are not THP. anyway, it is not making anything worse and always a win to move. > > I suppose a lot of developers are trying to avoid using mmap write > lock. I am also one of them. > > > Can we have some details on this to put in the commit log? > > For sure. Those judgments above should be placed in the > commit log. > > Thanks. Thanks barry