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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id C8BBAC433EF for ; Wed, 20 Apr 2022 11:29:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 426946B0075; Wed, 20 Apr 2022 07:29:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3D5356B007B; Wed, 20 Apr 2022 07:29:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 276276B007D; Wed, 20 Apr 2022 07:29:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.26]) by kanga.kvack.org (Postfix) with ESMTP id 141ED6B0075 for ; Wed, 20 Apr 2022 07:29:33 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id CD72122867 for ; Wed, 20 Apr 2022 11:29:32 +0000 (UTC) X-FDA: 79377036984.21.4519CEA Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.187]) by imf09.hostedemail.com (Postfix) with ESMTP id E29FD140012 for ; Wed, 20 Apr 2022 11:29:30 +0000 (UTC) Received: from mail-wr1-f46.google.com ([209.85.221.46]) by mrelayeu.kundenserver.de (mreue011 [213.165.67.97]) with ESMTPSA (Nemesis) id 1N0Fh1-1nsDSH2EmF-00xI2h for ; Wed, 20 Apr 2022 13:29:30 +0200 Received: by mail-wr1-f46.google.com with SMTP id x18so1871266wrc.0 for ; Wed, 20 Apr 2022 04:29:30 -0700 (PDT) X-Gm-Message-State: AOAM532z7a6UqqdJQcGjBp6IYlOYmz1yRh2y4t2zk6gEdzB2kVXTDUTG p+BI78OXgfL9BIz52LThsU/D5nshwciv06SOOPg= X-Google-Smtp-Source: ABdhPJzx9GpLsd2URZMHa2ZS0Kp2+Vi7HGOM42v7AVvlym/TS/rzY1VDK6lrg19sKIRqohNesRW/fM91dnNHk1s4f4A= X-Received: by 2002:a5d:6da5:0:b0:20a:8805:6988 with SMTP id u5-20020a5d6da5000000b0020a88056988mr13991084wrs.317.1650454169681; Wed, 20 Apr 2022 04:29:29 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Arnd Bergmann Date: Wed, 20 Apr 2022 13:29:13 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 07/10] crypto: Use ARCH_DMA_MINALIGN instead of ARCH_KMALLOC_MINALIGN To: Ard Biesheuvel Cc: Catalin Marinas , Herbert Xu , Will Deacon , Marc Zyngier , Arnd Bergmann , Greg Kroah-Hartman , Andrew Morton , Linus Torvalds , Linux Memory Management List , Linux ARM , Linux Kernel Mailing List , "David S. Miller" Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:DXAyxSVHg33Tv08lrPnkJqKgLlyzIabA1569YhEXpaIO+HbJksz eXSYCTrWu9gfArJay6vHT2+H+8DwYtMTzginQRV0Tk4nwXy0nuW9DyUyb54IAAcpnzB2Nl3 TD9buTgQVNM7CGJTJJBHGeGBAGJYZ6zMoyzHiFmFBjUQak8YTGi7pPN05t9nK1atHAmdJA9 AlazdU+yd5rWoJcHGEjEA== X-UI-Out-Filterresults: notjunk:1;V03:K0:37j/I7h5FOk=:Ylee9jQfHioTrJ+0PVxVo4 kteop+63ntawEvX4n7QiOlOsvteFMyrP3ZV9zf6XB2V+vmxHipHVySjAXvMIbqWnD9eelJZ9D 89An7KnNN7C+vEe7NhjKrR393vn4MBkHVV07Vx/mtJ3UkNgN7eeNTKXNlKh3wBpDf94y0KYwo 8OO1djcsukvnOIlRCjko1qSZUlxiwMohLrmNNdr86C9PJ81sGbQGSxEuKmc/MzZARMwEaGsZy QlfMPnf76UQQZ5InRo8FYdUIvZcPsCNrkuLJ39zGRJDzF2KfZZLIRp6ojW5VmKLYeNrsMC/p4 6fiR9pYrQNdgF9hmLGQzE7m2SC/ZpOBgPtizE5lMVKonwLeWy2UP8s2u8XoAHlCDv1NjCoJOr Yi3NpfOTaplV8Be7AiyBE+r9KonKp1egyDIyY7l5EUNFuAs2UGYKCOYeKHSvVeUUfNDJcumNX LJMy/QNRiMjFpsz3G8bEgvPkPEh1HxHisaMOcds0saCwFWn94MI8KH6/Quv/RLvN2fuL70mgu a40BjqGNGKPFBBovkvvrgm+CxgzTUyDQE3synDSv0/x3wn6SwfGwepnXbFQ4vNAp8ApoJKvey 9/wVDg8hDYGucjKOSGezznWNUEbgVAvWq43SIqqv+3UbPFyg2bgxO6vGIaoEaAUnT0zsRZWgS 4CmO+7j6Z7a8zlKGMbO7tf1sQQRd5ZsVnPO91x6dwzy+jCXUb3QmcZqAx75Qcv5itrpE= X-Rspam-User: X-Rspamd-Queue-Id: E29FD140012 X-Stat-Signature: es7y8rhkempdapja61dqdwo56qp7fuc1 Authentication-Results: imf09.hostedemail.com; dkim=none; spf=none (imf09.hostedemail.com: domain of arnd@arndb.de has no SPF policy when checking 212.227.126.187) smtp.mailfrom=arnd@arndb.de; dmarc=none X-Rspamd-Server: rspam01 X-HE-Tag: 1650454170-401241 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, Apr 19, 2022 at 11:50 PM Ard Biesheuvel wrote: > On Mon, 18 Apr 2022 at 18:44, Catalin Marinas wrote: > > On Mon, Apr 18, 2022 at 04:37:17PM +0800, Herbert Xu wrote: > > BTW before you have a go at this, there's also Linus' idea that does not > > change the crypto code (at least not functionally). Of course, you and > > Ard can still try to figure out how to reduce the padding but if we go > > with Linus' idea of a new GFP_NODMA flag, there won't be any changes to > > the crypto code as long as it doesn't pass such flag. So, the options: > > > > 1. Change ARCH_KMALLOC_MINALIGN to 8 (or ARCH_SLAB_MINALIGN if higher) > > while keeping ARCH_DMA_MINALIGN to 128. By default kmalloc() will > > honour the 128-byte alignment, unless GDP_NODMA is passed. This still > > requires changing CRYPTO_MINALIGN to ARCH_DMA_MINALIGN but there is > > no functional change, kmalloc() without the new flag will return > > CRYPTO_MINALIGN-aligned pointers. > > > > 2. Leave ARCH_KMALLOC_MINALIGN as ARCH_DMA_MINALIGN (128) and introduce > > a new GFP_PACKED (I think it fits better than 'NODMA') flag that > > reduces the minimum kmalloc() below ARCH_KMALLOC_MINALIGN (and > > probably at least ARCH_SLAB_MINALIGN). It's equivalent to (1) but > > does not touch the crypto code at all. > > > > (1) and (2) are the same, just minor naming difference. Happy to go with > > any of them. They still have the downside that we need to add the new > > GFP_ flag to those hotspots that allocate small objects (Arnd provided > > an idea on how to find them with ftrace) but at least we know it won't > > inadvertently break anything. Right, both of these seem reasonable to me. > I'm not sure GFP_NODMA adds much here. > > The way I see it, the issue in the crypto code is that we are relying > on a ARCH_KMALLOC_ALIGN aligned zero length __ctx[] array for three > different things: ... Right. So as long as the crypto subsystem has additional alignment requirement, it won't benefit from GFP_NODMA. For everything else, GFP_NODMA would however have a very direct and measuable impact on memory consumption. Your proposed changes to the crypto subsystem all seem helpful as well, just mostly orthogonal to the savings elsewhere. I don't know how much memory is permanently tied up in overaligned crypto data structures, but my guess is that it's not a lot on most systems. Improving the alignment for crypto would however likely help with stack usage on on-stack structures, and with performance when the amount of ctx memory to clear for each operation becomes smaller. Arnd