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=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,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 79055C433FE for ; Sat, 18 Sep 2021 10:51:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 56A1B60F48 for ; Sat, 18 Sep 2021 10:51:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238493AbhIRKxK (ORCPT ); Sat, 18 Sep 2021 06:53:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53702 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236901AbhIRKxI (ORCPT ); Sat, 18 Sep 2021 06:53:08 -0400 Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5E906C061574 for ; Sat, 18 Sep 2021 03:51:45 -0700 (PDT) Received: by mail-pj1-x102d.google.com with SMTP id me5-20020a17090b17c500b0019af76b7bb4so11150101pjb.2 for ; Sat, 18 Sep 2021 03:51:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xBFWMVLwmHIiRIbiBZy+2kXWxtuoqm6ONSYo0yLetxk=; b=wSs30QhbRby8deq8G74Z9mrupXOI0LHVqPjUhF7BA/lElDOz1xHJxU2OUwQDCQMNlh fvF2hX6tTH5AKwuwG0kHP4NgTot2e7T32S6It624AzA/V9YBszXbl0ShrCtbgnY184aO PHHeMGZo6u/fsaGL9rIsl13L/LDOVKVr/4A/f/3Pkn0xjoZC5nQA6jDQ/zRrBDOvkmEW oDtMOFBcjFAfgBI6RMHQhOomn9P4jQLiAiXLksx8sdR6m5pPiNRlljfj3SR4zHG21C2J c0uinWg4lus/S8aV+TFXOq3s/QldB4VIOYBh3VuK2GWuDEmbdUQmqtzVA8FgKE5c9CBm JOaw== 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=xBFWMVLwmHIiRIbiBZy+2kXWxtuoqm6ONSYo0yLetxk=; b=cujFp3+LZtEatLyWAsUQZeQ74nYApRRRdPDlHlgwFA1MpMbDX9YU0AAhOu/wp7XF6m r40vtdmDgZ0C0IxnRCCY8eNiZL5xxilN43kM95mW98LAj2/ZIxtVZzdrs90y4AaZT2ry Fh+VSlcIfZByLjoVa1rH0J9V+xHR7kiz8Z9UukmkAsaD0agsPRKMfUH0wJGJEFp+Fs1W wMo+XqB/IvLuFRFWKFhqmolb2t16HFrggwuqa1ud8Sb3VJhEMK3rtrCLUaz1IX8tM2zG 0yVCr6T7zblqzO3rBN6pbsSBgeflwaZ79LrP36zq+wdmhSsX4znKiTOySR4/gYWSx40v WBZw== X-Gm-Message-State: AOAM531JLi33sVSm6fXAoFyg0H94WRVrj6DUGcRev1vY0TkwrU/i1R+d wRQojHEQTG6aKxXq1Da+X9u6tto5bw3RHvLbJZEjzg== X-Google-Smtp-Source: ABdhPJxA0n1aW2qTA8q2EYKyRrnJdw0Nq1B3sRm0ZkNuBsUHNnADC9+jA1rOu2JCO4gYTVUHX/0OxXO6gzR+ZZT5MEA= X-Received: by 2002:a17:90b:4f8a:: with SMTP id qe10mr16148057pjb.5.1631962304832; Sat, 18 Sep 2021 03:51:44 -0700 (PDT) MIME-Version: 1.0 References: <20210917034815.80264-1-songmuchun@bytedance.com> <20210917034815.80264-4-songmuchun@bytedance.com> In-Reply-To: From: Muchun Song Date: Sat, 18 Sep 2021 18:51:07 +0800 Message-ID: Subject: Re: [PATCH RESEND v2 3/4] mm: sparsemem: use page table lock to protect kernel pmd operations To: Barry Song <21cnbao@gmail.com> 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 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. 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. 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=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,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 DF9F1C433EF for ; Sat, 18 Sep 2021 10:51:48 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 70A1E611C8 for ; Sat, 18 Sep 2021 10:51:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 70A1E611C8 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 A6F6A900002; Sat, 18 Sep 2021 06:51:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A20066B0072; Sat, 18 Sep 2021 06:51:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8E703900002; Sat, 18 Sep 2021 06:51:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 805FB6B0071 for ; Sat, 18 Sep 2021 06:51:47 -0400 (EDT) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 28D8B8248076 for ; Sat, 18 Sep 2021 10:51:47 +0000 (UTC) X-FDA: 78600378654.06.7BB3C51 Received: from mail-pj1-f51.google.com (mail-pj1-f51.google.com [209.85.216.51]) by imf25.hostedemail.com (Postfix) with ESMTP id 30E36B000189 for ; Sat, 18 Sep 2021 10:51:46 +0000 (UTC) Received: by mail-pj1-f51.google.com with SMTP id f3-20020a17090a638300b00199097ddf1aso11866903pjj.0 for ; Sat, 18 Sep 2021 03:51:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xBFWMVLwmHIiRIbiBZy+2kXWxtuoqm6ONSYo0yLetxk=; b=wSs30QhbRby8deq8G74Z9mrupXOI0LHVqPjUhF7BA/lElDOz1xHJxU2OUwQDCQMNlh fvF2hX6tTH5AKwuwG0kHP4NgTot2e7T32S6It624AzA/V9YBszXbl0ShrCtbgnY184aO PHHeMGZo6u/fsaGL9rIsl13L/LDOVKVr/4A/f/3Pkn0xjoZC5nQA6jDQ/zRrBDOvkmEW oDtMOFBcjFAfgBI6RMHQhOomn9P4jQLiAiXLksx8sdR6m5pPiNRlljfj3SR4zHG21C2J c0uinWg4lus/S8aV+TFXOq3s/QldB4VIOYBh3VuK2GWuDEmbdUQmqtzVA8FgKE5c9CBm JOaw== 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=xBFWMVLwmHIiRIbiBZy+2kXWxtuoqm6ONSYo0yLetxk=; b=Eq4aaZ3O5o7WLzDiECbTsdxM39MidKg5O3s0VoJd0jU8f8vSV809i6wMWb3PqIFAUF pc/xcBNLY2AMX+izrEqp8hls757XSVxyfW9SFAP0SQYkFaUSTGyLMjIRsQXME8tkEXVw JioWOPpmdZzrPDj6lPIzqAj2QaiY5DCYNYSesBYQuSAB+e+7da2I5ZoGMAP9otKUuNHX q68TH1XNkosMNtRwuDsYpb7KK07A96nYRT1jqDzy53DMzl9nGAHsttfyGcFp8noFvRYs QTXKMRfKnmj/XZDMc1EvBF7XpvMSh+yrwS3hMlouqiYRjSBEjSLEw1ikRZlE6Vweu6gw XBeA== X-Gm-Message-State: AOAM5318diYy/vcUTEPALKLiyGZBPUr+aEMLumqAoyL2C/3/Oaju3Aq5 Pdycipgg32Lk6CcKwoJpTPYVivBCBmGEVZ9fp1nCXQ== X-Google-Smtp-Source: ABdhPJxA0n1aW2qTA8q2EYKyRrnJdw0Nq1B3sRm0ZkNuBsUHNnADC9+jA1rOu2JCO4gYTVUHX/0OxXO6gzR+ZZT5MEA= X-Received: by 2002:a17:90b:4f8a:: with SMTP id qe10mr16148057pjb.5.1631962304832; Sat, 18 Sep 2021 03:51:44 -0700 (PDT) MIME-Version: 1.0 References: <20210917034815.80264-1-songmuchun@bytedance.com> <20210917034815.80264-4-songmuchun@bytedance.com> In-Reply-To: From: Muchun Song Date: Sat, 18 Sep 2021 18:51:07 +0800 Message-ID: Subject: Re: [PATCH RESEND v2 3/4] mm: sparsemem: use page table lock to protect kernel pmd operations To: Barry Song <21cnbao@gmail.com> 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: rspam01 X-Rspamd-Queue-Id: 30E36B000189 Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=wSs30Qhb; dmarc=pass (policy=none) header.from=bytedance.com; spf=pass (imf25.hostedemail.com: domain of songmuchun@bytedance.com designates 209.85.216.51 as permitted sender) smtp.mailfrom=songmuchun@bytedance.com X-Stat-Signature: jp6koik5aq3tfpd61ogj4w75ekjajp43 X-HE-Tag: 1631962306-206590 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 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. 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.