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 BCE62C433EF for ; Thu, 14 Apr 2022 05:40:20 +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:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=YqlnEBnYqmGwrf2YPY8k98F2GX3F73urCpMv7AY9frY=; b=ASBFhVoffzb4ex M5JimfYLe0lKnHajSv3xsVYDqfIf5566SpVweL9v8iy49s23z9lALeK+UANWLX4F7NP8pLSqzO3vv DqFqwlqrBRWhy5Jxze04gEGj9p2WDcSGyWN7Gd6XpxRXWJtYqPzE+cS4H/1npCZOPOEPtPtgbHc9G 2H72xx/FrWCdPWLTa1YvFu1mPt6FNOAoV+4Se/jouef8yZ/eZW3w9sjMNc8uS8RSRCjuReNNw1Z9K Kp2Mzt+RLTlQ0tx7IhJYKvWzEs9h9sz7H2Y+OFJ/Yd0tHaHtAp7wTGVoQhXzhbeV/qjEBE2ZZkakp kxBfAEItOuRcErZNdvMw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nesC7-003wyM-SU; Thu, 14 Apr 2022 05:39:03 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nesC4-003wxG-AD for linux-arm-kernel@lists.infradead.org; Thu, 14 Apr 2022 05:39:01 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 6641A61E29; Thu, 14 Apr 2022 05:38:59 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 49332C385A5; Thu, 14 Apr 2022 05:38:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1649914738; bh=EGbkB7EyGIphnUo8cRrJq675aEDUsCnVi4Pkg2u+IpI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=U/5xlB2FGJQ4d9YonjZ1eh/VOSVq/JGZbcaKEVZ/X3gneeL6e+c8n4oWQVEM2nC37 NUC4dasWX2knhep41oieB/4y70NBWjonRL99uQmXxgCzCTu04LVcoNKtRdt9zuG80Y UfyeJhMFJLi5uXjds7FMprNpoWpIZbZFFw7DiC/E= Date: Thu, 14 Apr 2022 07:38:56 +0200 From: Greg Kroah-Hartman To: Linus Torvalds Cc: Catalin Marinas , Ard Biesheuvel , Herbert Xu , Will Deacon , Marc Zyngier , Arnd Bergmann , Andrew Morton , Linux Memory Management List , Linux ARM , Linux Kernel Mailing List , "David S. Miller" Subject: Re: [PATCH 07/10] crypto: Use ARCH_DMA_MINALIGN instead of ARCH_KMALLOC_MINALIGN Message-ID: References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220413_223900_480406_5A3F0A45 X-CRM114-Status: GOOD ( 30.17 ) 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="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Apr 13, 2022 at 09:53:24AM -1000, Linus Torvalds wrote: > On Tue, Apr 12, 2022 at 10:47 PM Catalin Marinas > wrote: > > > > I agree. There is also an implicit expectation that the DMA API works on > > kmalloc'ed buffers and that's what ARCH_DMA_MINALIGN is for (and the > > dynamic arch_kmalloc_minalign() in this series). But the key point is > > that the driver doesn't need to know the CPU cache topology, coherency, > > the DMA API and kmalloc() take care of these. > > Honestly, I think it would probably be worth discussing the "kmalloc > DMA alignment" issues. > > 99.9% of kmalloc users don't want to do DMA. > > And there's actually a fair amount of small kmalloc for random stuff. > Right now on my laptop, I have > > kmalloc-8 16907 18432 8 512 1 : ... > > according to slabinfo, so almost 17 _thousand_ allocations of 8 bytes. > > It's all kinds of sad if those allocations need to be 64 bytes in size > just because of some silly DMA alignment issue, when none of them want > it. > > Yeah, yeah, wasting a megabyte of memory is "just a megabyte" these > days. Which is crazy. It's literally memory that could have been used > for something much more useful than just pure and utter waste. > > I think we could and should just say "people who actually require DMA > accesses should say so at kmalloc time". We literally have that > GFP_DMA and ZOME_DMA for various historical reasons, so we've been > able to do that before. > > No, that historical GFP_DMA isn't what arm64 wants - it's the old > crazy "legacy 16MB DMA" thing that ISA DMA used to have. > > But the basic issue was true then, and is true now - DMA allocations > are fairly special, and should not be that hard to just mark as such. "fairly special" == "all USB transactions", so it will take a lot of auditing here. I think also many SPI controllers require this and maybe I2C? Perhaps other bus types do as well. So please don't make this change without some way of figuring out just what drivers need to be fixed up, as it's going to be a lot... thanks, greg k-h _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel