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 96DCEC38A2D for ; Wed, 26 Oct 2022 17:47:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0502D8E0002; Wed, 26 Oct 2022 13:47:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F42018E0001; Wed, 26 Oct 2022 13:47:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E0A148E0002; Wed, 26 Oct 2022 13:47:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id CDF598E0001 for ; Wed, 26 Oct 2022 13:47:05 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 9E6641C3F38 for ; Wed, 26 Oct 2022 17:47:05 +0000 (UTC) X-FDA: 80063831610.21.BE8B122 Received: from mail-qt1-f174.google.com (mail-qt1-f174.google.com [209.85.160.174]) by imf15.hostedemail.com (Postfix) with ESMTP id 36101A0037 for ; Wed, 26 Oct 2022 17:47:05 +0000 (UTC) Received: by mail-qt1-f174.google.com with SMTP id r19so10512067qtx.6 for ; Wed, 26 Oct 2022 10:47:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ab1G9wzfb/QX50yjHzZMqPqB6T9ruvUBkM7syE04gVU=; b=ALx9mZUYIlDeJnEaNe05q0g/dWv3DabsjWk6aUCpeAR50bpAzf/Ww6hIWUVV6T+Zfa 9GhJnhUgS+MrQoC5V+Xi3QkIH4sRtV96gmCwmurrc9EBOmth+xMIhbgawLwzHO3hBK2q uO5wGPL2yCzcuU8c+W1SZYYZwBDCsU+MjB8WM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ab1G9wzfb/QX50yjHzZMqPqB6T9ruvUBkM7syE04gVU=; b=FjqECNWcdjWkY+4Dvz9QGfoIhUJyNYpHi2AmrymQdwDYiTtKj/5aLiUhctUqCrSz3n +UXvsxa7xecZtErU9b4rUbFL+dMdJe+XJS9G57bM3lteVzk815tm29QFp7BJnA7YowUg GvfB1mXnD+2i/VQgSykOCfie++Py49FIeLWoBGTOyY4/0qJy3N1iJIhUuHfVIYkzkkPb g8GWDgyOmkDAMgvcngSZVcF4T8SH9S2LyqB9rIBCu/e9DGCY0NP1WNdI5vhGrD4kWgdF yKyp/IuG8UWeeoaF2jTjzGZ21045LiEZKkBxTfY6B4Sf5NlDP94eDCxsCSF4FIWLu5hn 8UwQ== X-Gm-Message-State: ACrzQf3hjm1xVSg/y2OtczL2l5R4Jb7LhkqrqpHghgB8wY2wqgGTzeZP JBeieWboOayds7h4uLjRwZSGKSDbwS3MKQ== X-Google-Smtp-Source: AMsMyM4kLg8L0+/R42Lxd4D746nfWQgPvonEkkC/uuQUfMdejLUFdXSJ1J08IhyMosVksiYPjeXUCw== X-Received: by 2002:a05:622a:490:b0:39c:c82d:557c with SMTP id p16-20020a05622a049000b0039cc82d557cmr38121599qtx.463.1666806424120; Wed, 26 Oct 2022 10:47:04 -0700 (PDT) Received: from mail-yb1-f172.google.com (mail-yb1-f172.google.com. [209.85.219.172]) by smtp.gmail.com with ESMTPSA id y21-20020a05620a44d500b006eed75805a2sm4373635qkp.126.2022.10.26.10.47.02 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 26 Oct 2022 10:47:02 -0700 (PDT) Received: by mail-yb1-f172.google.com with SMTP id t186so19846947yba.12 for ; Wed, 26 Oct 2022 10:47:02 -0700 (PDT) X-Received: by 2002:a25:bb44:0:b0:6bb:a336:7762 with SMTP id b4-20020a25bb44000000b006bba3367762mr39225762ybk.501.1666806422139; Wed, 26 Oct 2022 10:47:02 -0700 (PDT) MIME-Version: 1.0 References: <20221025205247.3264568-1-catalin.marinas@arm.com> <20221025205247.3264568-3-catalin.marinas@arm.com> In-Reply-To: From: Linus Torvalds Date: Wed, 26 Oct 2022 10:46:46 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 2/2] treewide: Add the __GFP_PACKED flag to several non-DMA kmalloc() allocations To: Catalin Marinas Cc: Greg Kroah-Hartman , Arnd Bergmann , Will Deacon , Marc Zyngier , Andrew Morton , Herbert Xu , Ard Biesheuvel , Christoph Hellwig , Isaac Manjarres , Saravana Kannan , linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1666806425; a=rsa-sha256; cv=none; b=KD4olbQ0RBfnb3wBY0YHxRaNusPWIv2/7lYZyqLiXFqdproVj6XiodPys+Qw+XTSwIknkB YDo4vtht5DyPYZcy8v33YnYXTsv9lpKmpXxpIEQNBRI41UlKsz5ktRxpDdArGUzt4BOz+b XwnIdwT0mMnEpu/upAYOdVVeagGRJMw= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=ALx9mZUY; dmarc=none; spf=pass (imf15.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.160.174 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1666806425; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ab1G9wzfb/QX50yjHzZMqPqB6T9ruvUBkM7syE04gVU=; b=d0jVwPubBMoh+SNhpnscj5UXAubjPFa3w/T7oMfVUsHjlRP3itLyqgWUZ9MbNAc1A40wpH GXcMg6XnuU7fHJJVnOOCqoEVcUydE5drkMMxjobu/0fk81G05dgdDjvqB3w9IQTHCVeDoH 2WO1GVpfYZxeoWk/JEMjwCf35wWZqN8= X-Rspamd-Queue-Id: 36101A0037 Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=ALx9mZUY; dmarc=none; spf=pass (imf15.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.160.174 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org X-Rspamd-Server: rspam12 X-Rspam-User: X-Stat-Signature: 617gyrasey4atjt8pc5odr64ertei5mu X-HE-Tag: 1666806425-70775 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 Wed, Oct 26, 2022 at 2:49 AM Catalin Marinas wrote: > > Linus originally suggested GFP_NODMA. We could go with that (and a > corresponding KMALLOC_NODMA_MINALIGN). If we do negative a "mark this for smaller allocations because it cannot do DMA", then yes, I would still prefer GFP_NODMA to make it explicit that it's about DMA. But if we're marking allocations, I'd still prefer a "positive" marking over a negative one, so it would still be much preferable to just have GFP_DMA and various explicit DMA allocators. One argument for doing it that way - aside from just the "let's use positive markers, not negative ones" - is that then the pain of discovery ends up being solidly on the broken cases, not on sane architectures with sane platforms. Seriously, non-cache coherent DMA in 2022 is a sign of an incompetent platform architect or hardware designer, and at some point I think that should just be called out for the incredible garbage it is. It was always garbage, but at least it was excusable garbage back in the days. And we have a long history of marking DMA allocations specially, thanks to the original 16MB DMA limit of the ISA PC/AT platform. That was garbage too, but hey, people acknowledged that, and it got fixed. I think we should just stop bending over backwards over this, and say "if your DMA isn't coherent, it's on your driver to mark its allocations". Yes, yes, I realize that there are a billion devices. But not only is the whole "a billion flies can't be wrong" still wrong, but most of those billion devices often look remarkably similar, so it's not a billion drivers. It's a few drivers, and a few driver subsystems, and it sounds like Greg would prefer the "explicit dma allocations" at least for USB. And yes, there are also a few oddball people who love and stick to their old broken hardware, in some kind of strange Stockholm syndrome thing from fond memories of when they grew up with broken hardware and they love the "quirks" of it. That hardware may then be one of the one-off strange cases, but those people with their masochistic tendencies can take the pain of "oh, now I need to mark my broken driver with dma_alloc()". They'll probably even enjoy it, the poor sods. Linus