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 5705EC433F5 for ; Wed, 13 Apr 2022 19:53:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A5CBD6B0072; Wed, 13 Apr 2022 15:53:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9E5206B0083; Wed, 13 Apr 2022 15:53:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 885C56B0085; Wed, 13 Apr 2022 15:53:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.28]) by kanga.kvack.org (Postfix) with ESMTP id 72DAE6B0072 for ; Wed, 13 Apr 2022 15:53:47 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay13.hostedemail.com (Postfix) with ESMTP id 466C06239B for ; Wed, 13 Apr 2022 19:53:47 +0000 (UTC) X-FDA: 79352906094.01.6FDE061 Received: from mail-lj1-f181.google.com (mail-lj1-f181.google.com [209.85.208.181]) by imf30.hostedemail.com (Postfix) with ESMTP id B331E80004 for ; Wed, 13 Apr 2022 19:53:46 +0000 (UTC) Received: by mail-lj1-f181.google.com with SMTP id q14so3486057ljc.12 for ; Wed, 13 Apr 2022 12:53:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=q/DBgAkv4OQEV7GLgkTJlWv+q3kLHi60Bd65fMkiVGg=; b=dxlaLoqslihL0u5ALJQQNQLkyAJAatT6/BflQltbOe8/sf91WvaHNbi7GO1b9Fv7ym eGx41ozm92iUi2qBs53105A6bIUDq03qjk/3IVzSMTq9V8X0glNvjMmX3ZXtjpTtmSaa IGbV8DgLGUxm4m7Y3DonNhNx06/iV90eFeUS0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=q/DBgAkv4OQEV7GLgkTJlWv+q3kLHi60Bd65fMkiVGg=; b=UN7/jjbUNKu8JQpyrk3RQSyP+R7LII6/yQcZ38yQFw7R8U0jSEabjLSrLvDiYgYSjs sSDgnPb1pXKKOpc6UbV2GZSTzyHNRJMZMcoWHv3JXEVXnVHa6REZtceJiefWhmK8Qihg E3poglj+gSmPU7iwuOy07N5oQgEXzJj59NvoBVg4ccW/bnWeSxZ3/u+toJYmbQIuQes9 dLJz5PPZLsfqkuaqHmUpFpFy2/HNivBm2rJF9yI+BSrDViufcdjUOlASFRxjupJs6muJ 1/qbWj7+KpMF7mgB66cQ9Cs5AIx7gUlvZZ2uSinrpxz/Smw9LArQSpo8dUT5reSRzvYj eJyA== X-Gm-Message-State: AOAM531Sz65ihEZLcFuzeWuCphK8R+tWknI5Vi/u5Jt9bt4ChLsO7OOM g/XK/2ojz7QJzmiJB9tKbPPhvYbsjHyKmGUh X-Google-Smtp-Source: ABdhPJwe1vkT0ujXHFTdixS8/bBR2zBqHMPFenYN5UF44J13cCTIEwFD9Rc7FWFET5e4fWPNcuyzhg== X-Received: by 2002:a05:651c:2119:b0:24b:546b:5f93 with SMTP id a25-20020a05651c211900b0024b546b5f93mr16087697ljq.374.1649879624730; Wed, 13 Apr 2022 12:53:44 -0700 (PDT) Received: from mail-lf1-f54.google.com (mail-lf1-f54.google.com. [209.85.167.54]) by smtp.gmail.com with ESMTPSA id 26-20020ac24d5a000000b0046ba2c20d79sm1397309lfp.206.2022.04.13.12.53.40 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 13 Apr 2022 12:53:42 -0700 (PDT) Received: by mail-lf1-f54.google.com with SMTP id x33so5484009lfu.1 for ; Wed, 13 Apr 2022 12:53:40 -0700 (PDT) X-Received: by 2002:ac2:4203:0:b0:448:8053:d402 with SMTP id y3-20020ac24203000000b004488053d402mr28805493lfh.687.1649879620574; Wed, 13 Apr 2022 12:53:40 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Linus Torvalds Date: Wed, 13 Apr 2022 09:53:24 -1000 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 07/10] crypto: Use ARCH_DMA_MINALIGN instead of ARCH_KMALLOC_MINALIGN To: Catalin Marinas Cc: Ard Biesheuvel , Herbert Xu , Will Deacon , Marc Zyngier , Arnd Bergmann , Greg Kroah-Hartman , Andrew Morton , Linux Memory Management List , Linux ARM , Linux Kernel Mailing List , "David S. Miller" Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: dga9t7f9pmbd4qhsjmukc3ufffix94he Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=dxlaLoqs; spf=pass (imf30.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.181 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: B331E80004 X-HE-Tag: 1649879626-96778 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 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. We could add a trivial wrapper function like static void *dma_kmalloc(size_t size) { return kmalloc(size | (ARCH_DMA_MINALIGN-1); } which now means that the size argument is guaranteed to be big enough (not not overflow to zero) that you get that aligned memory allocation. We could perhaps even have other special rules. Including really specific ones, like saying - allocations smaller than 32 bytes are not DMA coherent, because we pack them which would allow those small allocations to not pointlessly waste memory. I dunno. But it's ridiculous that arm64 wastes so much memory when it's approximately never needed. Linus