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 BBC9BC433F5 for ; Sun, 2 Oct 2022 17:00:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E620B6B0072; Sun, 2 Oct 2022 13:00:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DEA816B0073; Sun, 2 Oct 2022 13:00:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C63578D0001; Sun, 2 Oct 2022 13:00:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id AD85F6B0072 for ; Sun, 2 Oct 2022 13:00:35 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 7EFB71C5D42 for ; Sun, 2 Oct 2022 17:00:35 +0000 (UTC) X-FDA: 79976623230.02.DE2D16B Received: from mail-oa1-f54.google.com (mail-oa1-f54.google.com [209.85.160.54]) by imf27.hostedemail.com (Postfix) with ESMTP id ED3C540018 for ; Sun, 2 Oct 2022 17:00:33 +0000 (UTC) Received: by mail-oa1-f54.google.com with SMTP id 586e51a60fabf-1326637be6eso996190fac.13 for ; Sun, 02 Oct 2022 10:00:33 -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; bh=QgT+0pE5+Jxg1Db0pjr/6GUR7lMe+WJC6D7WdnY3dDY=; b=Nzqj81O4P6j0wFJ6dCNqILguy0U5N+2OxhQjCFfKYDAC6M6UpY7hAq5wpd1cfw2nTd hSmo4qXcfU8ubm0sRDL10bN31XVYLOYrsXrrc2Oa+eXTJc9tQv8ii7M5hGagWac1Lm3y j4zJLaHZhsFQufPX3m6IxXYXKG+dcxt9QVs7k= 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; bh=QgT+0pE5+Jxg1Db0pjr/6GUR7lMe+WJC6D7WdnY3dDY=; b=VFcmN1bLJKJTatM4H1tXlI2FV8KXhhWDpj9nR4H8mxuisNOiit8h2bxv4x6F4+hKfB ckDz+pnWIt6VUu+pCmpl74E4xJ4BNlr5PwEwdusZAwTncG5FS0JTa0fq5Vv0vLgAQLTj wDNvwPuC6VcwEAproRRMoy2GUZRY9K99kDD+1cIj/rhEuO/t4aIoOUIrsAlBRPIFcJLv PMGZdcFy8eC633cYTYGBXLtbS6dLiv7saZ4Q3LfFphdZ0qjrlj0FUFzoPWHsXlHJ2eUw OPr4BqLOIxDCNrUoXuWT9jEwUnr7o2sv5RihS1RLH9/LTj6QTLd3vXsCfrGwfJlD9tsl GAkw== X-Gm-Message-State: ACrzQf1E49I+K8ijjmZDZUYHLXCB/iYW0PmOPJ9v4TyER/oYhiMtWr/v oInlur6mAK6WQHHtGXhDb0tnI3FyD5FzzA== X-Google-Smtp-Source: AMsMyM7kZOnI0Dy37XQAmYnKhXvI5nxoSsFQBjQIcUut5vdmlYtQ7MScLhuWX7twiPfD6ZnPkQz5lg== X-Received: by 2002:a05:6870:15d4:b0:12b:8d8d:1001 with SMTP id k20-20020a05687015d400b0012b8d8d1001mr3587582oad.137.1664730032575; Sun, 02 Oct 2022 10:00:32 -0700 (PDT) Received: from mail-oo1-f45.google.com (mail-oo1-f45.google.com. [209.85.161.45]) by smtp.gmail.com with ESMTPSA id 6-20020aca0506000000b003509cc4ad4esm1931091oif.39.2022.10.02.10.00.28 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 02 Oct 2022 10:00:29 -0700 (PDT) Received: by mail-oo1-f45.google.com with SMTP id r15-20020a4abf0f000000b004761c7e6be1so5426511oop.9 for ; Sun, 02 Oct 2022 10:00:28 -0700 (PDT) X-Received: by 2002:a05:6830:11c6:b0:65f:913:ff93 with SMTP id v6-20020a05683011c600b0065f0913ff93mr2396114otq.69.1664730028572; Sun, 02 Oct 2022 10:00:28 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Linus Torvalds Date: Sun, 2 Oct 2022 10:00:12 -0700 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: Isaac Manjarres , Herbert Xu , Ard Biesheuvel , Will Deacon , Marc Zyngier , Arnd Bergmann , Greg Kroah-Hartman , Andrew Morton , Linux Memory Management List , Linux ARM , Linux Kernel Mailing List , "David S. Miller" , Saravana Kannan , kernel-team@android.com Content-Type: text/plain; charset="UTF-8" ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=Nzqj81O4; spf=pass (imf27.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.160.54 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1664730034; a=rsa-sha256; cv=none; b=1QWqkH/g+P9AZrV+zw+hUMKxXsTBKO07i0vO6CdvuwuYpITABcXsMMknxGWlSdaHi2+1rh ijiHawHd5Ix92Qpx98oIHAMfDs4EBnnPcBqtfkIz82HolK3rk3CmOZbqZqO3VD4jQxZA1L upK0z1Y151cyqQ+88ln6q2aj7HghRmQ= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1664730034; 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=QgT+0pE5+Jxg1Db0pjr/6GUR7lMe+WJC6D7WdnY3dDY=; b=2jCm8/b8atNlO8dz610puk4nRT6ofr8Auij6z8p97jVTJZcBehOxNxPq19ZLFigUFRfIL/ F8bwEXIGl3ZcUEdrxOg3oV566krKAAKgQEZfUoEvsne3wp5jXEVyMiu+VDCj9a4ecUJ/5u PSJw3YqS5C9P8RW/PtKzYwGMKynq46k= X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: ED3C540018 X-Rspam-User: Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=Nzqj81O4; spf=pass (imf27.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.160.54 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none X-Stat-Signature: stzyhdqgfo39y58yk1s4dw1xqdawbumk X-HE-Tag: 1664730033-68735 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 Sat, Oct 1, 2022 at 3:30 PM Catalin Marinas wrote: > > The "force bouncing" in my series currently only checks for small > (potentially kmalloc'ed) sizes under the assumption that intra-object > DMA buffers were properly aligned to 128. So for something like below: Ahh, so your forced bouncing isn't actually safe. I would have hoped (but obviously never checked) that the force bouncing be made really safe and look at the actual alignment of the DMA (comparing it to the hardware coherency requirements), so that alignment at allocation time simply wouldn't matter. At that point, places like the ones you found would still work, they'd just cause bouncing. At which point you'd then have a choice of (a) just let it bounce (b) marking the allocations that led to them and (a) might actually be perfectly fine in a lot of situations. That's particularly true for the "random drivers" situation that may not be all that relevant in real life, which is a *big* deal. Not because of any performance issues, but simply because of kernel developers not having to worry their pretty little heads about stuff that doesn't really matter. In fact, (a) might be perfectly ok even for drivers that *do* matter, if they just aren't all that performance-critical and the situation doesn't come up a lot (maybe it's a special management ioctl or similar that just causes the possibility to come up, and it's important that it *works*, but having a few bounces occasionally doesn't actually matter, and all the regular IO goes the normal path). And (b) would be triggered by actual data. Which could be fairly easy to gather with a statistical model. For example, just making dma_map_xyz() have a debug mode where it prints out the stack trace of these bounces once every minute or so - statistically the call trace will be one of the hot ones. Or, better yet, just use tracing to do it. That would allow us to say "DMA is immaterial for _correct_ alignment, because we always fix it up if required", but then also find situations where we might want to give it a gentle helper nudge. But hey, if you're comfortable with your approach, that's fine too. Anything that gets rid of the absolutely insane "you can't do small allocations" is an improvement. Linus