Received: by 2002:a05:6a10:6d10:0:0:0:0 with SMTP id gq16csp841259pxb; Thu, 21 Apr 2022 11:30:09 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyhmiSM30Mv+2qNSV+dSjFtcT84e3MJps06n3KSJLPr4vLpz3jEOyN1ZVs+dGLmwgp/SmLL X-Received: by 2002:a17:906:8554:b0:6e8:c43c:12b3 with SMTP id h20-20020a170906855400b006e8c43c12b3mr702369ejy.331.1650565809321; Thu, 21 Apr 2022 11:30:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1650565809; cv=none; d=google.com; s=arc-20160816; b=pzjOmSvW7sgQK6sjWctIBtB+GR5U+ocKP0dlbRVln4lRUILcAulxg+Y4I0y8wdNK67 IH44XtStktvrbs6VyX5tYQn8FXmAPpQYny9r0ir+ixHUBYuWR5Mryi9SYHnC9S3caY8/ igcELk9ai9sSMmO5PLLZK1uDc7xfjHa7ZYrQl93B6cSZY38cimd16oflGgp6qJQYPB1Q 51O5sclypk1y1w5eiEpI0g2VgTjPfu2gxL47itFL4qnrMPrcbtvTbCHsKUAVqsF+bbU5 xSSCFB4HgKZVcviucspzwGNzECQblTiB1ZRAcanczEhfvVng1r4NT8Zo6w4hD7GcGOGh MlSg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version; bh=6dhBjzIcH+W88AhQPu0167W1A0ZBETH0OEAhpxtQ/WI=; b=YkHccif+vWfDGxIsUuOzERljOM3UcrjsmaAniccG0zhxN6TVXwTt7xRtkAnO4dKB0p fo5t3DnCHlFsEtrkL7cDxvuSlJQ87gXKStDUPbrUy7ayyHzjdYf/QbgR6IEdQI5hKEuW ShgFL0B+vI0UcMpNsCBx2UcqUqEOyYM2s/ViQXOj0NcsyOdaTALIMpr8v+zGxVh3LeLO 8D/oS0rWEY3sorX7og4gy577uXJjlfuILarF0NKKjT2LKKc4waDMrox/i4iOSXtdbRa/ q1eVAo8cys2HC8SciapOvb5/mfXEQQRXjTi2MxAjRhYKJVwRooYFJUhBBNQXNhMefzU6 1+vg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id kf12-20020a17090776cc00b006efd8c768aasi4322766ejc.405.2022.04.21.11.29.45; Thu, 21 Apr 2022 11:30:09 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1378105AbiDTLcV (ORCPT + 99 others); Wed, 20 Apr 2022 07:32:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39586 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1378102AbiDTLcT (ORCPT ); Wed, 20 Apr 2022 07:32:19 -0400 Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.134]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7FF364163F for ; Wed, 20 Apr 2022 04:29:31 -0700 (PDT) Received: from mail-wr1-f45.google.com ([209.85.221.45]) by mrelayeu.kundenserver.de (mreue012 [213.165.67.97]) with ESMTPSA (Nemesis) id 1MVaQW-1nX88618su-00RXol for ; Wed, 20 Apr 2022 13:29:30 +0200 Received: by mail-wr1-f45.google.com with SMTP id g18so1809442wrb.10 for ; Wed, 20 Apr 2022 04:29:30 -0700 (PDT) X-Gm-Message-State: AOAM533wKlqvtuQtFBTB7gY7L4BDix2jVYNFnesvGKQ53jhBOOjQMM5s Ujh29rE/DxZq1884Fz14UaG9tWEC41oCQsUXnSI= 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:FbQGnzRMGUp6v7xMxeWkNEPDfRyA1JaFCAbaC7RWmyxTt2bs4Ay NZFiuQ06+aKjquWu3GU5Ket5Y/1Iyfkooyoby1tLLZg0NreZ5DYjbVdaGcpoaJl9EyZBoK1 cnBR4Zu6SipnWVG8cV18yJJTUav5bAmXW/UxjcTqbJFywok3mOtkFFbUoPzV4wKnnWvK2Y2 hHb+F+fZzAieTGA3fg2Yw== X-UI-Out-Filterresults: notjunk:1;V03:K0:HGLnGFU59rg=:/HO7d5VXb2KNTskQvcH35V XW2T30MeOntfgGxO3pAgNMFD1SbXPfCxaaLYI30AhLlgbljD57T/0eL6S+88eRRYpaMwWSrOb RteOWaV6QLdoYmx07Y86PEU5hZ6CVgMiWYhSzI56JmnqTh5ZKL01NAFNM10YOUv7pWBHyjHvL 4Xg6Psc1tpMlFZolYHMKkfriFyP8yasq/1oXti7u1jNtrun0N1k8uTT6v7h4hfmMoy/HawHdY KFluq6Y1m5DeBhCrRjkFBkDZcfkwPBlfy0XyVCZLiHvCOakW8ImaFED9ITJP28dpVJC/Jspkt Q9D47wH7eh5Kvp9AnXxYF++LWyePUDDNgO9olNpB0a3eilH3GEumIGw7RqnW20VhcWpJy7shv 1S9EDSZzXOZEFxF928d6LOB+M1ASylzrr05MNMxUzRf+vho3hdtVFLxvISlP6PTvGrPfR6mR/ R40SeCwu4LMxw+PXP8uQyCK0P8u6ZkzuGDgO5uTUOMgAJhdquIulikLoPqJyM20HTXjRcWuw/ iEnPENJ2KdlM0bCL56mTN9T98922cdW49TlKsNGcsRaI+x/iVmgOhkcZWv81t3p0rb/5G8Ixz sN+NMolmigIxM8GPtD6ES0GhXtE46QfPt44JyMUNJYm12aju5LY4FGbOLSmifXQHPapUSTkSK khohFfsCJ+Sd9nCfdkIFsK9U2EvKGCRmMlDyqvV5QyA0O/i43A0qm/YqRvM7Nu/xj+0E= X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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