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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1C0BCC433F5 for ; Tue, 18 Jan 2022 03:09:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348607AbiARDJe (ORCPT ); Mon, 17 Jan 2022 22:09:34 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37382 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1350973AbiARC5t (ORCPT ); Mon, 17 Jan 2022 21:57:49 -0500 Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9F100C061369; Mon, 17 Jan 2022 18:46:08 -0800 (PST) Received: by mail-pf1-x42a.google.com with SMTP id i129so11790039pfe.13; Mon, 17 Jan 2022 18:46:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:subject:to:cc:references:in-reply-to:mime-version :message-id:content-transfer-encoding; bh=G7afKiI+gE5BvcSZZNsZkHZKk4Ry06NGlI7r6RoEIKE=; b=Rc1D2DDu80wX82f3gReKMipNgtke5Ezoh5+9wP1vhbdzaMaDpuqodjUEIPM3EEkN6e LgXUN0zYcVseRq4Frignh/DJoa5B+ejI/R86K6gVUs4KSmZonAsG8E+ISC0wxiWbybhF sFXificRMOC2xpZ7KtIqyN2K0aiCO/s3go8noGaQHXcR+uqcDSh1kZsVYezqUxmq0/qz OL7tPvDnqbGNxHrMNvu+qIsoAgVc3qknGLNJvsmigTagPY6FxXNh9CcCOocBbit0S/bj QPOQoHItg72E/0+7MKT2m9nJCpmvz86e5RNpYYVLdt6+9paqz1AbJhAaBBdVWxJ7Li6P etFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:subject:to:cc:references:in-reply-to :mime-version:message-id:content-transfer-encoding; bh=G7afKiI+gE5BvcSZZNsZkHZKk4Ry06NGlI7r6RoEIKE=; b=bGo1MGEhM1ChG7I/K76Gp4/BUvW/FjLe7eZcnMH6s/XPM6BzSJEGNMtU9vmxWGr1k5 TtXt1wSw9lByS5vR7k9he7Dslk2r06ih5MGpcA23vmqWfZEuGNIC3RpD9A5QT97W6hc3 Tpd2aA2qN70xQggEaA9hhKf5Q26fcLKedL07p1mvtbDCHSyQqr3uzq6xdjv3dp5M497e xEWvrBquoWmwLyewvv9ycWnVt0ZMZCtrfNPQjlIhIr93tUrYaz/kvtaUiJINN89TpD8S 0lDoiB9Rxm89YE+dx59G0C6jAh6drUfYQiwUplE6kOJrS4X+V/qiEum1ky6jU2SE9Q0V lQlQ== X-Gm-Message-State: AOAM533RomxH7em7w8/g6A6gcxdpWUnGkfiDGB32jeXb/Imyj73kQtPH sDXWf8Ze5cCYxt8CpJqivS8= X-Google-Smtp-Source: ABdhPJwaTkO88Si8cY9Mt/mQhv8ZpVANJ2CdFYnmVifrVKXyLg/EiyceiwxjR12ycsrWtesBCh7+Uw== X-Received: by 2002:a63:8c57:: with SMTP id q23mr21680397pgn.625.1642473968155; Mon, 17 Jan 2022 18:46:08 -0800 (PST) Received: from localhost (124-171-74-95.tpgi.com.au. [124.171.74.95]) by smtp.gmail.com with ESMTPSA id i123sm12180204pfe.13.2022.01.17.18.46.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 17 Jan 2022 18:46:07 -0800 (PST) Date: Tue, 18 Jan 2022 12:46:01 +1000 From: Nicholas Piggin Subject: Re: [PATCH v2 3/3] x86: Support huge vmalloc mappings To: Andrew Morton , Jonathan Corbet , Dave Hansen , linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org, Kefeng Wang , x86@kernel.org Cc: Benjamin Herrenschmidt , Borislav Petkov , Catalin Marinas , Christophe Leroy , Dave Hansen , "H. Peter Anvin" , Ingo Molnar , Michael Ellerman , Paul Mackerras , Thomas Gleixner , Will Deacon , Matthew Wilcox References: <20211227145903.187152-1-wangkefeng.wang@huawei.com> <20211227145903.187152-4-wangkefeng.wang@huawei.com> <70ff58bc-3a92-55c2-2da8-c5877af72e44@intel.com> <3858de1f-cdbc-ff52-2890-4254d0f48b0a@huawei.com> <31a75f95-6e6e-b640-2d95-08a95ea8cf51@intel.com> In-Reply-To: <31a75f95-6e6e-b640-2d95-08a95ea8cf51@intel.com> MIME-Version: 1.0 Message-Id: <1642472965.lgfksp6krp.astroid@bobo.none> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org Excerpts from Dave Hansen's message of December 29, 2021 2:14 am: > On 12/28/21 2:26 AM, Kefeng Wang wrote: >>>> There are some disadvantages about this feature[2], one of the main >>>> concerns is the possible memory fragmentation/waste in some scenarios, >>>> also archs must ensure that any arch specific vmalloc allocations that >>>> require PAGE_SIZE mappings(eg, module alloc with STRICT_MODULE_RWX) >>>> use the VM_NO_HUGE_VMAP flag to inhibit larger mappings. >>> That just says that x86 *needs* PAGE_SIZE allocations.=C2=A0 But, what >>> happens if VM_NO_HUGE_VMAP is not passed (like it was in v1)?=C2=A0 Wil= l the >>> subsequent permission changes just fragment the 2M mapping? >>=20 >> Yes, without VM_NO_HUGE_VMAP, it could fragment the 2M mapping. >>=20 >> When module alloc with STRICT_MODULE_RWX on x86, it calls >> __change_page_attr() >>=20 >> from set_memory_ro/rw/nx which will split large page, so there is no >> need to make >>=20 >> module alloc with HUGE_VMALLOC. >=20 > This all sounds very fragile to me. Every time a new architecture would > get added for huge vmalloc() support, the developer needs to know to go > find that architecture's module_alloc() and add this flag. This is documented in the Kconfig. # # Archs that select this would be capable of PMD-sized vmaps (i.e., # arch_vmap_pmd_supported() returns true), and they must make no assumpti= ons # that vmalloc memory is mapped with PAGE_SIZE ptes. The VM_NO_HUGE_VMAP = flag # can be used to prohibit arch-specific allocations from using hugepages = to # help with this (e.g., modules may require it). # config HAVE_ARCH_HUGE_VMALLOC depends on HAVE_ARCH_HUGE_VMAP bool Is it really fair to say it's *very* fragile? Surely it's reasonable to=20 read the (not very long) documentation ad understand the consequences for the arch code before enabling it. > They next > guy is going to forget, just like you did. The miss here could just be a simple oversight or thinko, and caught by=20 review, as happens to a lot of things. >=20 > Considering that this is not a hot path, a weak function would be a nice > choice: >=20 > /* vmalloc() flags used for all module allocations. */ > unsigned long __weak arch_module_vm_flags() > { > /* > * Modules use a single, large vmalloc(). Different > * permissions are applied later and will fragment > * huge mappings. Avoid using huge pages for modules. > */ > return VM_NO_HUGE_VMAP; > } >=20 > Stick that in some the common module code, next to: Then they have to think about it even less, so I don't know if that's an=20 improvement. I don't know what else an arch might be doing with these allocations, at least modules will blow up pretty quickly, who knows=20 what other rare code relies on 4k vmalloc mappings? The huge vmalloc option is not supposed to be easy to enable. This is=20 the same problem Andy was having with the TLB shootdown patches, he=20 didn't read the documentation and thought it was supposed to be a=20 trivial thing anybody could enable without thinking about it, and was dutifully pointing out the the nasty "bugs" the feature has in it if x86 were to enable it improperly. Thanks, Nick >=20 >> void * __weak module_alloc(unsigned long size) >> { >> return __vmalloc_node_range(size, 1, VMALLOC_START, VMALLOC_END, > ... >=20 > Then, put arch_module_vm_flags() in *all* of the module_alloc() > implementations, including the generic one. That way (even with a new > architecture) whoever copies-and-pastes their module_alloc() > implementation is likely to get it right. The next guy who just does a > "select HAVE_ARCH_HUGE_VMALLOC" will hopefully just work. >=20 > VM_FLUSH_RESET_PERMS could probably be dealt with in the same way. >=20 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 Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 09671C4167E for ; Tue, 18 Jan 2022 02:46:54 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4JdCpj29q8z3bTg for ; Tue, 18 Jan 2022 13:46:53 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=Rc1D2DDu; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gmail.com (client-ip=2607:f8b0:4864:20::52e; helo=mail-pg1-x52e.google.com; envelope-from=npiggin@gmail.com; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=Rc1D2DDu; dkim-atps=neutral Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4JdCnv6Bnpz2ynK for ; Tue, 18 Jan 2022 13:46:11 +1100 (AEDT) Received: by mail-pg1-x52e.google.com with SMTP id f8so12576788pgf.8 for ; Mon, 17 Jan 2022 18:46:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:subject:to:cc:references:in-reply-to:mime-version :message-id:content-transfer-encoding; bh=G7afKiI+gE5BvcSZZNsZkHZKk4Ry06NGlI7r6RoEIKE=; b=Rc1D2DDu80wX82f3gReKMipNgtke5Ezoh5+9wP1vhbdzaMaDpuqodjUEIPM3EEkN6e LgXUN0zYcVseRq4Frignh/DJoa5B+ejI/R86K6gVUs4KSmZonAsG8E+ISC0wxiWbybhF sFXificRMOC2xpZ7KtIqyN2K0aiCO/s3go8noGaQHXcR+uqcDSh1kZsVYezqUxmq0/qz OL7tPvDnqbGNxHrMNvu+qIsoAgVc3qknGLNJvsmigTagPY6FxXNh9CcCOocBbit0S/bj QPOQoHItg72E/0+7MKT2m9nJCpmvz86e5RNpYYVLdt6+9paqz1AbJhAaBBdVWxJ7Li6P etFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:subject:to:cc:references:in-reply-to :mime-version:message-id:content-transfer-encoding; bh=G7afKiI+gE5BvcSZZNsZkHZKk4Ry06NGlI7r6RoEIKE=; b=sPPE2CpUiZQ88QLFVd2abDHYjGWY5UWmMSmJyBgOVVHRkcdaUtrGVFhqOjgjXZH7qe 0FSiduFaXwKQ/AwCJ8zIS/YOdtdWuS+oMKMBmU7xqnn+IrdGbE7jjcRHHO7tAU6PwGg8 WV0jymYDoHgjiRaGod8T2MB1mI9bqKhWWv1O55AiM72Kvvc44ieyeYBPNTiJrIiJgl+m mB8Yn070+Wmg/l3Wv8hCyI5XRiGhYvxsRStfsIRevOMWW/5Q5CMXInief56hHOqU7hfG P2HFXzMuU54YDhohZH0quNsAxDdbTCk3ycC7njHlpMiymh3m4UGcZoq9xlk5deauZOwd fLyQ== X-Gm-Message-State: AOAM5321yQy0WArlMMUO4PwpSK7zttCpYWiXZ+tpW3k5XnE8fLONgT9t dH7HD+2nNXp7UTvEHoWsHww= X-Google-Smtp-Source: ABdhPJwaTkO88Si8cY9Mt/mQhv8ZpVANJ2CdFYnmVifrVKXyLg/EiyceiwxjR12ycsrWtesBCh7+Uw== X-Received: by 2002:a63:8c57:: with SMTP id q23mr21680397pgn.625.1642473968155; Mon, 17 Jan 2022 18:46:08 -0800 (PST) Received: from localhost (124-171-74-95.tpgi.com.au. [124.171.74.95]) by smtp.gmail.com with ESMTPSA id i123sm12180204pfe.13.2022.01.17.18.46.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 17 Jan 2022 18:46:07 -0800 (PST) Date: Tue, 18 Jan 2022 12:46:01 +1000 From: Nicholas Piggin Subject: Re: [PATCH v2 3/3] x86: Support huge vmalloc mappings To: Andrew Morton , Jonathan Corbet , Dave Hansen , linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org, Kefeng Wang , x86@kernel.org References: <20211227145903.187152-1-wangkefeng.wang@huawei.com> <20211227145903.187152-4-wangkefeng.wang@huawei.com> <70ff58bc-3a92-55c2-2da8-c5877af72e44@intel.com> <3858de1f-cdbc-ff52-2890-4254d0f48b0a@huawei.com> <31a75f95-6e6e-b640-2d95-08a95ea8cf51@intel.com> In-Reply-To: <31a75f95-6e6e-b640-2d95-08a95ea8cf51@intel.com> MIME-Version: 1.0 Message-Id: <1642472965.lgfksp6krp.astroid@bobo.none> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Matthew Wilcox , Catalin Marinas , Dave Hansen , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Paul Mackerras , Thomas Gleixner , Will Deacon Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" Excerpts from Dave Hansen's message of December 29, 2021 2:14 am: > On 12/28/21 2:26 AM, Kefeng Wang wrote: >>>> There are some disadvantages about this feature[2], one of the main >>>> concerns is the possible memory fragmentation/waste in some scenarios, >>>> also archs must ensure that any arch specific vmalloc allocations that >>>> require PAGE_SIZE mappings(eg, module alloc with STRICT_MODULE_RWX) >>>> use the VM_NO_HUGE_VMAP flag to inhibit larger mappings. >>> That just says that x86 *needs* PAGE_SIZE allocations.=C2=A0 But, what >>> happens if VM_NO_HUGE_VMAP is not passed (like it was in v1)?=C2=A0 Wil= l the >>> subsequent permission changes just fragment the 2M mapping? >>=20 >> Yes, without VM_NO_HUGE_VMAP, it could fragment the 2M mapping. >>=20 >> When module alloc with STRICT_MODULE_RWX on x86, it calls >> __change_page_attr() >>=20 >> from set_memory_ro/rw/nx which will split large page, so there is no >> need to make >>=20 >> module alloc with HUGE_VMALLOC. >=20 > This all sounds very fragile to me. Every time a new architecture would > get added for huge vmalloc() support, the developer needs to know to go > find that architecture's module_alloc() and add this flag. This is documented in the Kconfig. # # Archs that select this would be capable of PMD-sized vmaps (i.e., # arch_vmap_pmd_supported() returns true), and they must make no assumpti= ons # that vmalloc memory is mapped with PAGE_SIZE ptes. The VM_NO_HUGE_VMAP = flag # can be used to prohibit arch-specific allocations from using hugepages = to # help with this (e.g., modules may require it). # config HAVE_ARCH_HUGE_VMALLOC depends on HAVE_ARCH_HUGE_VMAP bool Is it really fair to say it's *very* fragile? Surely it's reasonable to=20 read the (not very long) documentation ad understand the consequences for the arch code before enabling it. > They next > guy is going to forget, just like you did. The miss here could just be a simple oversight or thinko, and caught by=20 review, as happens to a lot of things. >=20 > Considering that this is not a hot path, a weak function would be a nice > choice: >=20 > /* vmalloc() flags used for all module allocations. */ > unsigned long __weak arch_module_vm_flags() > { > /* > * Modules use a single, large vmalloc(). Different > * permissions are applied later and will fragment > * huge mappings. Avoid using huge pages for modules. > */ > return VM_NO_HUGE_VMAP; > } >=20 > Stick that in some the common module code, next to: Then they have to think about it even less, so I don't know if that's an=20 improvement. I don't know what else an arch might be doing with these allocations, at least modules will blow up pretty quickly, who knows=20 what other rare code relies on 4k vmalloc mappings? The huge vmalloc option is not supposed to be easy to enable. This is=20 the same problem Andy was having with the TLB shootdown patches, he=20 didn't read the documentation and thought it was supposed to be a=20 trivial thing anybody could enable without thinking about it, and was dutifully pointing out the the nasty "bugs" the feature has in it if x86 were to enable it improperly. Thanks, Nick >=20 >> void * __weak module_alloc(unsigned long size) >> { >> return __vmalloc_node_range(size, 1, VMALLOC_START, VMALLOC_END, > ... >=20 > Then, put arch_module_vm_flags() in *all* of the module_alloc() > implementations, including the generic one. That way (even with a new > architecture) whoever copies-and-pastes their module_alloc() > implementation is likely to get it right. The next guy who just does a > "select HAVE_ARCH_HUGE_VMALLOC" will hopefully just work. >=20 > VM_FLUSH_RESET_PERMS could probably be dealt with in the same way. >=20 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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 2536AC433EF for ; Tue, 18 Jan 2022 03:28:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Message-Id:MIME-Version:In-Reply-To: References:Cc:To:Subject:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=Up+X0pJD76EphL9qwnxLKeziq+aC7rPiG/1e+nl0H9s=; b=GFk10pmWC6fTUu 3NBuJhDzk5dcuYivtG5yVclGIODCHnfIYHZUdMq3K6ZmEZ8rmrA9BQ8dDPaYlDXrdMVVV0Di8WhSc CbmpatT5sFMkMbchc8ZDbSRY138BjVrpzdPYHvz8puQjZ+CNUZWoNFwdmkzJgqIj4KJq0rgTvIcLC tat/EzvEgJ6sOkqrPfA4nAh9p9vmnKi2wyO6yY3qc8q31/pMbs/UWF/gwmf22v4bFAtJyn3bxzc4b Mqm2e4IgBr0G2MBq20dXjdPlJic9Kvv4rf1GqLPLkMvoJCyUd3R9xmFTVQv9V4lfDwpF2SOkKKU39 TPiLkveMiVXnGoDxnEiA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1n9f8X-00HRiP-E2; Tue, 18 Jan 2022 03:26:23 +0000 Received: from mail-pg1-x52e.google.com ([2607:f8b0:4864:20::52e]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1n9eVd-00H6CT-O1 for linux-arm-kernel@lists.infradead.org; Tue, 18 Jan 2022 02:46:11 +0000 Received: by mail-pg1-x52e.google.com with SMTP id j64so934491pgd.6 for ; Mon, 17 Jan 2022 18:46:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:subject:to:cc:references:in-reply-to:mime-version :message-id:content-transfer-encoding; bh=G7afKiI+gE5BvcSZZNsZkHZKk4Ry06NGlI7r6RoEIKE=; b=Rc1D2DDu80wX82f3gReKMipNgtke5Ezoh5+9wP1vhbdzaMaDpuqodjUEIPM3EEkN6e LgXUN0zYcVseRq4Frignh/DJoa5B+ejI/R86K6gVUs4KSmZonAsG8E+ISC0wxiWbybhF sFXificRMOC2xpZ7KtIqyN2K0aiCO/s3go8noGaQHXcR+uqcDSh1kZsVYezqUxmq0/qz OL7tPvDnqbGNxHrMNvu+qIsoAgVc3qknGLNJvsmigTagPY6FxXNh9CcCOocBbit0S/bj QPOQoHItg72E/0+7MKT2m9nJCpmvz86e5RNpYYVLdt6+9paqz1AbJhAaBBdVWxJ7Li6P etFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:subject:to:cc:references:in-reply-to :mime-version:message-id:content-transfer-encoding; bh=G7afKiI+gE5BvcSZZNsZkHZKk4Ry06NGlI7r6RoEIKE=; b=fWH0ghP8c7R+sjfPQwO87JZ07yhRo+GMZY+bGvixkSDh+O4m0wC6xrAP91WbOGNpXC gCIXNF2svAYR3ZlgvedWjeKf6ZUJcAX9EN6Jejvluj1uEl503qwoS32qy2nmaD1UrZrF E5EpjR5aktrJfDMXLKOHV9qrt4FcuKBy9IHtKnwXpPhOsrkdgJQ3Lrdhufpmobrb4VYw GFz0+bWWHzdfham3xRPuQFtYfwvD75kAyzvF6NbFdyxwS8gW7G194ZFXZZ7FksZO6xCe tExKsTFvAPREMm9kXSU5IQiOsbzUoqV7lvdHOJAysVleo3oEqdUpoidZtfvydvqJ1oFX KfSw== X-Gm-Message-State: AOAM530CWcPJGHzxSXR71DsyNfybO1bwNj4CXwCLYpkLl9K9R7VVFOr3 rH1gTLyOUL+o/Jnql647pjI= X-Google-Smtp-Source: ABdhPJwaTkO88Si8cY9Mt/mQhv8ZpVANJ2CdFYnmVifrVKXyLg/EiyceiwxjR12ycsrWtesBCh7+Uw== X-Received: by 2002:a63:8c57:: with SMTP id q23mr21680397pgn.625.1642473968155; Mon, 17 Jan 2022 18:46:08 -0800 (PST) Received: from localhost (124-171-74-95.tpgi.com.au. [124.171.74.95]) by smtp.gmail.com with ESMTPSA id i123sm12180204pfe.13.2022.01.17.18.46.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 17 Jan 2022 18:46:07 -0800 (PST) Date: Tue, 18 Jan 2022 12:46:01 +1000 From: Nicholas Piggin Subject: Re: [PATCH v2 3/3] x86: Support huge vmalloc mappings To: Andrew Morton , Jonathan Corbet , Dave Hansen , linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org, Kefeng Wang , x86@kernel.org Cc: Benjamin Herrenschmidt , Borislav Petkov , Catalin Marinas , Christophe Leroy , Dave Hansen , "H. Peter Anvin" , Ingo Molnar , Michael Ellerman , Paul Mackerras , Thomas Gleixner , Will Deacon , Matthew Wilcox References: <20211227145903.187152-1-wangkefeng.wang@huawei.com> <20211227145903.187152-4-wangkefeng.wang@huawei.com> <70ff58bc-3a92-55c2-2da8-c5877af72e44@intel.com> <3858de1f-cdbc-ff52-2890-4254d0f48b0a@huawei.com> <31a75f95-6e6e-b640-2d95-08a95ea8cf51@intel.com> In-Reply-To: <31a75f95-6e6e-b640-2d95-08a95ea8cf51@intel.com> MIME-Version: 1.0 Message-Id: <1642472965.lgfksp6krp.astroid@bobo.none> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220117_184609_860697_99CAE5BE X-CRM114-Status: GOOD ( 24.84 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org RXhjZXJwdHMgZnJvbSBEYXZlIEhhbnNlbidzIG1lc3NhZ2Ugb2YgRGVjZW1iZXIgMjksIDIwMjEg MjoxNCBhbToKPiBPbiAxMi8yOC8yMSAyOjI2IEFNLCBLZWZlbmcgV2FuZyB3cm90ZToKPj4+PiBU aGVyZSBhcmUgc29tZSBkaXNhZHZhbnRhZ2VzIGFib3V0IHRoaXMgZmVhdHVyZVsyXSwgb25lIG9m IHRoZSBtYWluCj4+Pj4gY29uY2VybnMgaXMgdGhlIHBvc3NpYmxlIG1lbW9yeSBmcmFnbWVudGF0 aW9uL3dhc3RlIGluIHNvbWUgc2NlbmFyaW9zLAo+Pj4+IGFsc28gYXJjaHMgbXVzdCBlbnN1cmUg dGhhdCBhbnkgYXJjaCBzcGVjaWZpYyB2bWFsbG9jIGFsbG9jYXRpb25zIHRoYXQKPj4+PiByZXF1 aXJlIFBBR0VfU0laRSBtYXBwaW5ncyhlZywgbW9kdWxlIGFsbG9jIHdpdGggU1RSSUNUX01PRFVM RV9SV1gpCj4+Pj4gdXNlIHRoZSBWTV9OT19IVUdFX1ZNQVAgZmxhZyB0byBpbmhpYml0IGxhcmdl ciBtYXBwaW5ncy4KPj4+IFRoYXQganVzdCBzYXlzIHRoYXQgeDg2ICpuZWVkcyogUEFHRV9TSVpF IGFsbG9jYXRpb25zLsKgIEJ1dCwgd2hhdAo+Pj4gaGFwcGVucyBpZiBWTV9OT19IVUdFX1ZNQVAg aXMgbm90IHBhc3NlZCAobGlrZSBpdCB3YXMgaW4gdjEpP8KgIFdpbGwgdGhlCj4+PiBzdWJzZXF1 ZW50IHBlcm1pc3Npb24gY2hhbmdlcyBqdXN0IGZyYWdtZW50IHRoZSAyTSBtYXBwaW5nPwo+PiAK Pj4gWWVzLCB3aXRob3V0IFZNX05PX0hVR0VfVk1BUCwgaXQgY291bGQgZnJhZ21lbnQgdGhlIDJN IG1hcHBpbmcuCj4+IAo+PiBXaGVuIG1vZHVsZSBhbGxvYyB3aXRoIFNUUklDVF9NT0RVTEVfUldY IG9uIHg4NiwgaXQgY2FsbHMKPj4gX19jaGFuZ2VfcGFnZV9hdHRyKCkKPj4gCj4+IGZyb20gc2V0 X21lbW9yeV9yby9ydy9ueCB3aGljaCB3aWxsIHNwbGl0IGxhcmdlIHBhZ2UsIHNvIHRoZXJlIGlz IG5vCj4+IG5lZWQgdG8gbWFrZQo+PiAKPj4gbW9kdWxlIGFsbG9jIHdpdGggSFVHRV9WTUFMTE9D Lgo+IAo+IFRoaXMgYWxsIHNvdW5kcyB2ZXJ5IGZyYWdpbGUgdG8gbWUuICBFdmVyeSB0aW1lIGEg bmV3IGFyY2hpdGVjdHVyZSB3b3VsZAo+IGdldCBhZGRlZCBmb3IgaHVnZSB2bWFsbG9jKCkgc3Vw cG9ydCwgdGhlIGRldmVsb3BlciBuZWVkcyB0byBrbm93IHRvIGdvCj4gZmluZCB0aGF0IGFyY2hp dGVjdHVyZSdzIG1vZHVsZV9hbGxvYygpIGFuZCBhZGQgdGhpcyBmbGFnLgoKVGhpcyBpcyBkb2N1 bWVudGVkIGluIHRoZSBLY29uZmlnLgoKICMKICMgIEFyY2hzIHRoYXQgc2VsZWN0IHRoaXMgd291 bGQgYmUgY2FwYWJsZSBvZiBQTUQtc2l6ZWQgdm1hcHMgKGkuZS4sCiAjICBhcmNoX3ZtYXBfcG1k X3N1cHBvcnRlZCgpIHJldHVybnMgdHJ1ZSksIGFuZCB0aGV5IG11c3QgbWFrZSBubyBhc3N1bXB0 aW9ucwogIyAgdGhhdCB2bWFsbG9jIG1lbW9yeSBpcyBtYXBwZWQgd2l0aCBQQUdFX1NJWkUgcHRl cy4gVGhlIFZNX05PX0hVR0VfVk1BUCBmbGFnCiAjICBjYW4gYmUgdXNlZCB0byBwcm9oaWJpdCBh cmNoLXNwZWNpZmljIGFsbG9jYXRpb25zIGZyb20gdXNpbmcgaHVnZXBhZ2VzIHRvCiAjICBoZWxw IHdpdGggdGhpcyAoZS5nLiwgbW9kdWxlcyBtYXkgcmVxdWlyZSBpdCkuCiAjCiBjb25maWcgSEFW RV9BUkNIX0hVR0VfVk1BTExPQwogICAgICAgICBkZXBlbmRzIG9uIEhBVkVfQVJDSF9IVUdFX1ZN QVAKICAgICAgICAgYm9vbAoKSXMgaXQgcmVhbGx5IGZhaXIgdG8gc2F5IGl0J3MgKnZlcnkqIGZy YWdpbGU/IFN1cmVseSBpdCdzIHJlYXNvbmFibGUgdG8gCnJlYWQgdGhlIChub3QgdmVyeSBsb25n KSBkb2N1bWVudGF0aW9uIGFkIHVuZGVyc3RhbmQgdGhlIGNvbnNlcXVlbmNlcyBmb3IKdGhlIGFy Y2ggY29kZSBiZWZvcmUgZW5hYmxpbmcgaXQuCgo+IFRoZXkgbmV4dAo+IGd1eSBpcyBnb2luZyB0 byBmb3JnZXQsIGp1c3QgbGlrZSB5b3UgZGlkLgoKVGhlIG1pc3MgaGVyZSBjb3VsZCBqdXN0IGJl IGEgc2ltcGxlIG92ZXJzaWdodCBvciB0aGlua28sIGFuZCBjYXVnaHQgYnkgCnJldmlldywgYXMg aGFwcGVucyB0byBhIGxvdCBvZiB0aGluZ3MuCgo+IAo+IENvbnNpZGVyaW5nIHRoYXQgdGhpcyBp cyBub3QgYSBob3QgcGF0aCwgYSB3ZWFrIGZ1bmN0aW9uIHdvdWxkIGJlIGEgbmljZQo+IGNob2lj ZToKPiAKPiAvKiB2bWFsbG9jKCkgZmxhZ3MgdXNlZCBmb3IgYWxsIG1vZHVsZSBhbGxvY2F0aW9u cy4gKi8KPiB1bnNpZ25lZCBsb25nIF9fd2VhayBhcmNoX21vZHVsZV92bV9mbGFncygpCj4gewo+ IAkvKgo+IAkgKiBNb2R1bGVzIHVzZSBhIHNpbmdsZSwgbGFyZ2Ugdm1hbGxvYygpLiAgRGlmZmVy ZW50Cj4gCSAqIHBlcm1pc3Npb25zIGFyZSBhcHBsaWVkIGxhdGVyIGFuZCB3aWxsIGZyYWdtZW50 Cj4gCSAqIGh1Z2UgbWFwcGluZ3MuICBBdm9pZCB1c2luZyBodWdlIHBhZ2VzIGZvciBtb2R1bGVz Lgo+IAkgKi8KPiAJcmV0dXJuIFZNX05PX0hVR0VfVk1BUDsKPiB9Cj4gCj4gU3RpY2sgdGhhdCBp biBzb21lIHRoZSBjb21tb24gbW9kdWxlIGNvZGUsIG5leHQgdG86CgpUaGVuIHRoZXkgaGF2ZSB0 byB0aGluayBhYm91dCBpdCBldmVuIGxlc3MsIHNvIEkgZG9uJ3Qga25vdyBpZiB0aGF0J3MgYW4g CmltcHJvdmVtZW50LiBJIGRvbid0IGtub3cgd2hhdCBlbHNlIGFuIGFyY2ggbWlnaHQgYmUgZG9p bmcgd2l0aCB0aGVzZQphbGxvY2F0aW9ucywgYXQgbGVhc3QgbW9kdWxlcyB3aWxsIGJsb3cgdXAg cHJldHR5IHF1aWNrbHksIHdobyBrbm93cyAKd2hhdCBvdGhlciByYXJlIGNvZGUgcmVsaWVzIG9u IDRrIHZtYWxsb2MgbWFwcGluZ3M/CgpUaGUgaHVnZSB2bWFsbG9jIG9wdGlvbiBpcyBub3Qgc3Vw cG9zZWQgdG8gYmUgZWFzeSB0byBlbmFibGUuIFRoaXMgaXMgCnRoZSBzYW1lIHByb2JsZW0gQW5k eSB3YXMgaGF2aW5nIHdpdGggdGhlIFRMQiBzaG9vdGRvd24gcGF0Y2hlcywgaGUgCmRpZG4ndCBy ZWFkIHRoZSBkb2N1bWVudGF0aW9uIGFuZCB0aG91Z2h0IGl0IHdhcyBzdXBwb3NlZCB0byBiZSBh IAp0cml2aWFsIHRoaW5nIGFueWJvZHkgY291bGQgZW5hYmxlIHdpdGhvdXQgdGhpbmtpbmcgYWJv dXQgaXQsIGFuZCB3YXMKZHV0aWZ1bGx5IHBvaW50aW5nIG91dCB0aGUgdGhlIG5hc3R5ICJidWdz IiB0aGUgZmVhdHVyZSBoYXMgaW4gaXQgaWYKeDg2IHdlcmUgdG8gZW5hYmxlIGl0IGltcHJvcGVy bHkuCgpUaGFua3MsCk5pY2sKCj4gCj4+IHZvaWQgKiBfX3dlYWsgbW9kdWxlX2FsbG9jKHVuc2ln bmVkIGxvbmcgc2l6ZSkKPj4gewo+PiAgICAgICAgIHJldHVybiBfX3ZtYWxsb2Nfbm9kZV9yYW5n ZShzaXplLCAxLCBWTUFMTE9DX1NUQVJULCBWTUFMTE9DX0VORCwKPiAuLi4KPiAKPiBUaGVuLCBw dXQgYXJjaF9tb2R1bGVfdm1fZmxhZ3MoKSBpbiAqYWxsKiBvZiB0aGUgbW9kdWxlX2FsbG9jKCkK PiBpbXBsZW1lbnRhdGlvbnMsIGluY2x1ZGluZyB0aGUgZ2VuZXJpYyBvbmUuICBUaGF0IHdheSAo ZXZlbiB3aXRoIGEgbmV3Cj4gYXJjaGl0ZWN0dXJlKSB3aG9ldmVyIGNvcGllcy1hbmQtcGFzdGVz IHRoZWlyIG1vZHVsZV9hbGxvYygpCj4gaW1wbGVtZW50YXRpb24gaXMgbGlrZWx5IHRvIGdldCBp dCByaWdodC4gIFRoZSBuZXh0IGd1eSB3aG8ganVzdCBkb2VzIGEKPiAic2VsZWN0IEhBVkVfQVJD SF9IVUdFX1ZNQUxMT0MiIHdpbGwgaG9wZWZ1bGx5IGp1c3Qgd29yay4KPiAKPiBWTV9GTFVTSF9S RVNFVF9QRVJNUyBjb3VsZCBwcm9iYWJseSBiZSBkZWFsdCB3aXRoIGluIHRoZSBzYW1lIHdheS4K PiAKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmxpbnV4 LWFybS1rZXJuZWwgbWFpbGluZyBsaXN0CmxpbnV4LWFybS1rZXJuZWxAbGlzdHMuaW5mcmFkZWFk Lm9yZwpodHRwOi8vbGlzdHMuaW5mcmFkZWFkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LWFy bS1rZXJuZWwK