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.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 265E3C388F7 for ; Tue, 10 Nov 2020 05:17:51 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7828C207BC for ; Tue, 10 Nov 2020 05:17:50 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=bytedance-com.20150623.gappssmtp.com header.i=@bytedance-com.20150623.gappssmtp.com header.b="pLvSIdTa" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7828C207BC Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=bytedance.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id CA5756B005C; Tue, 10 Nov 2020 00:17:49 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C564C6B005D; Tue, 10 Nov 2020 00:17:49 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B1E886B006C; Tue, 10 Nov 2020 00:17:49 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0168.hostedemail.com [216.40.44.168]) by kanga.kvack.org (Postfix) with ESMTP id 824EF6B005C for ; Tue, 10 Nov 2020 00:17:49 -0500 (EST) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 29DF8181AEF1A for ; Tue, 10 Nov 2020 05:17:49 +0000 (UTC) X-FDA: 77467351458.14.night91_4510511272f2 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin14.hostedemail.com (Postfix) with ESMTP id 05DD318229818 for ; Tue, 10 Nov 2020 05:17:48 +0000 (UTC) X-HE-Tag: night91_4510511272f2 X-Filterd-Recvd-Size: 5482 Received: from mail-pg1-f195.google.com (mail-pg1-f195.google.com [209.85.215.195]) by imf07.hostedemail.com (Postfix) with ESMTP for ; Tue, 10 Nov 2020 05:17:48 +0000 (UTC) Received: by mail-pg1-f195.google.com with SMTP id r186so9172213pgr.0 for ; Mon, 09 Nov 2020 21:17:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CXC+/BleOfXkT9eayj4GUbnHyl7/dt6Mpch3dxKG+nw=; b=pLvSIdTaeIZHJo73IcVYhLxFlNpiP4U6E3UKJdrJ72FklZtdmaGGtdRYddauYc8rsf 8vGAqMuYP6aoyQytiHO2wXjeJlQwD1esvWvuzjQG96OuCScE4Q6yvoGenHz0oL5Jz9rL 7xELZc6ZqX07o5yxmTRVqs7HeXzXw4TkUxxyy8X//4qS7fYZ8VOEWDyMAcqwnoUJRWoB Y1SewOEXaBVU+S2DHHL2EjGLtCKyC/aoubsWEd/7zVcu87dPcAp9cgoBqu152E8MViw/ Oei0lNDfYCSQ7ABLbplQc90cCWxeuTtUGtXRm95kwl1Y5sf/fDRn5MeRezrjhPOLOVCX E4qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CXC+/BleOfXkT9eayj4GUbnHyl7/dt6Mpch3dxKG+nw=; b=X18v+A+cOTtTBzVG5o/xQt0VbLNLmuon3eJ5vaOvNrmF+h2xj/zDnWv4/0J38TO9mX jedkUwbGGsfKKZ9UJyLYlDyUVIodjj79O/8Vq0Rp5Kms1KdUvEB0Vvo9Q5VhpfyJ4rPu 9GSpG2VAa96yFETCcB69FlCiCJ2mdbgWET8jJCiX8Q7CFI+sR04zZOw2adBGPKV0Xwqo 07LT3JS+XCrIyHcsIB2upRC6GveaQNlKiONosV2215EdKIue9BZbSoS/xR1khc0jl7Fy bK1ywEGKu4k4aVnyct5bP/llJ4nuLUbwK9QDl3jbew///ZnkgKU4J0TbADu7cYNQFk+l hBtQ== X-Gm-Message-State: AOAM531ehIUVlZO7KlSa1UH9DojfYef/Qx70s/5tgHZYvB+dD+sFtuPn C5G2AsGC/VGoDZFZUJwNavzr7OwHcqwRlMv39vYRwQ== X-Google-Smtp-Source: ABdhPJw1XsBVc5s3suqABD9CcUsJOcngWrKu6Nkz0r9C1MF0alZME/00oO9I8hsjaBLtSiYVkkFfsBc/QpbX3EWvfKM= X-Received: by 2002:a65:5383:: with SMTP id x3mr15431908pgq.341.1604985467243; Mon, 09 Nov 2020 21:17:47 -0800 (PST) MIME-Version: 1.0 References: <20201108141113.65450-1-songmuchun@bytedance.com> <20201108141113.65450-9-songmuchun@bytedance.com> <20201109181104.GC17356@linux> In-Reply-To: <20201109181104.GC17356@linux> From: Muchun Song Date: Tue, 10 Nov 2020 13:17:11 +0800 Message-ID: Subject: Re: [External] Re: [PATCH v3 08/21] mm/vmemmap: Initialize page table lock for vmemmap To: Oscar Salvador Cc: Jonathan Corbet , Mike Kravetz , Thomas Gleixner , mingo@redhat.com, bp@alien8.de, x86@kernel.org, hpa@zytor.com, dave.hansen@linux.intel.com, luto@kernel.org, Peter Zijlstra , viro@zeniv.linux.org.uk, Andrew Morton , paulmck@kernel.org, mchehab+huawei@kernel.org, pawan.kumar.gupta@linux.intel.com, Randy Dunlap , oneukum@suse.com, anshuman.khandual@arm.com, jroedel@suse.de, Mina Almasry , David Rientjes , Matthew Wilcox , Michal Hocko , Xiongchun duan , linux-doc@vger.kernel.org, LKML , Linux Memory Management List , linux-fsdevel Content-Type: text/plain; charset="UTF-8" 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 Tue, Nov 10, 2020 at 2:11 AM Oscar Salvador wrote: > > On Sun, Nov 08, 2020 at 10:11:00PM +0800, Muchun Song wrote: > > In the register_page_bootmem_memmap, the slab allocator is not ready > > yet. So when ALLOC_SPLIT_PTLOCKS, we use init_mm.page_table_lock. > > otherwise we use per page table lock(page->ptl). In the later patch, > > we will use the vmemmap page table lock to guard the splitting of > > the vmemmap huge PMD. > > I am not sure about this one. > Grabbing init_mm's pagetable lock for specific hugetlb operations does not > seem like a good idea, and we do not know how contented is that one. These APIs are used to guard the operations on vmemmap page tables. For now, it is only for specific hugetlb operations. But maybe in the future, someone also wants to modify the vmemmap page tables, he also can use these APIs. Yeah, we do not know how contented is init_mm's pagetable lock. Grabbing this one may not be a good idea. > > I think a better fit would be to find another hook to initialize > page_table_lock at a later stage. > Anyway, we do not need till we are going to perform an operation > on the range, right? Yeah. You are right. > > Unless I am missing something, this should be doable in hugetlb_init. > > hugetlb_init is part from a init_call that gets called during do_initcalls. > At this time, slab is fully operative. If we initialize the page_table_lock in the hugetlb_init, we need to walk the vmemmap page tables again. But the vmemmap pages size is small, maybe the overhead of this is also small. And doing this in hugetlb_init can make the code cleaner. Thanks very much. > > start_kernel > kmem_cache_init_late > kmem_cache_init_late > ... > arch_call_rest_init > rest_init > kernel_init_freeable > do_basic_setup > do_initcalls > hugetlb_init > > -- > Oscar Salvador > SUSE L3 -- Yours, Muchun