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 6EE38C4332F for ; Wed, 12 Oct 2022 17:46:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BEA136B0071; Wed, 12 Oct 2022 13:46:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B9A236B0073; Wed, 12 Oct 2022 13:46:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A3CA56B0074; Wed, 12 Oct 2022 13:46:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 91A566B0071 for ; Wed, 12 Oct 2022 13:46:03 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 2F131C0938 for ; Wed, 12 Oct 2022 17:46:03 +0000 (UTC) X-FDA: 80013025806.07.E2E46DC Received: from mail-pj1-f48.google.com (mail-pj1-f48.google.com [209.85.216.48]) by imf25.hostedemail.com (Postfix) with ESMTP id AB6F1A001F for ; Wed, 12 Oct 2022 17:46:02 +0000 (UTC) Received: by mail-pj1-f48.google.com with SMTP id fw14so15896023pjb.3 for ; Wed, 12 Oct 2022 10:46:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=iadacU8HjMHZCZhJygxiIG7/MygN7METMFxWBA2IfjE=; b=Yf1mCOSuC0WDz6zTEAp5QbI0HxH6ymxd5/zia+3afDO9yUKDLS+JDYybBqIpyHg2Dm LWkFjYvZlU+lltgGLwmCmY0sjldmPQKxu+JgxLtghVhKKE9d2EGEo+4yL94ZOAonjxeV kbj59D/U9GRzVI/buQnBYqv35sfmPZojLKOw5xjRiaI4ZELfvb/wGHiFtRagCRnx8ZcY 1Q2dHtoW+D8FBefYRYVjTKHhY/gfwrZKot2sJULgk+EIeE0Ckuti06zdPv2Ov1Wei8vx t5+V2RKfZU6QUWknZ5QRlC7CW9PWtEWhquV1zMTl8C3mmCuTW7lX/uMUWODsxD2bXs1u Kc7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=iadacU8HjMHZCZhJygxiIG7/MygN7METMFxWBA2IfjE=; b=2ksvGM/oASmkqU46qLfNf6yY7MsJei7/wZLXR30f6Ito8AFrrszyToUs6Lw+7zooi9 oN7wKgqYLEZklzZG2zop/nTDd+UJd7VfgWiFASxcJeQy6he6ibOuhnzcj+tBPKgwFXFe +MG3BX7xtcB5vbgwFKCFNGnrpzwWwXmqVUvupXTK0+f1CDRx5LkhYQuZ/YoqvZd2Pjcn kbRexpNHTLF+Tyr6AFStXKrGZzX3M/mAMh/Dgh4c6DKZRPwm7o8+MynQewllV3Xwudq6 EhGrSsCtO6msv9CVlbWBo6OwonIljEIZBh/sEI/pqph4xFwHoef6Q/gHiVoFqD7kcm4U kN7w== X-Gm-Message-State: ACrzQf248o8WOBmnzJkXYvVk5XrfAHnZ4LoQiXSggBvaDqHCeHIGlF6M AM87FupMgzgAZ6BqTev7M9u2BNsJo6Snzy3m X-Google-Smtp-Source: AMsMyM7vJ/PR4P14DLQBaJpzHCGqSoud7gaIwx0eOUsQHSMeqXrfDtMP4isskWzcfYApPERl8yACrg== X-Received: by 2002:a17:902:dad1:b0:183:243c:d0d0 with SMTP id q17-20020a170902dad100b00183243cd0d0mr13409687plx.157.1665596751184; Wed, 12 Oct 2022 10:45:51 -0700 (PDT) Received: from google.com ([2620:15c:2d:3:5351:89a8:5e92:8bed]) by smtp.gmail.com with ESMTPSA id t8-20020a170902e84800b00185002f0c6csm197132plg.134.2022.10.12.10.45.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 12 Oct 2022 10:45:50 -0700 (PDT) Date: Wed, 12 Oct 2022 10:45:45 -0700 From: Isaac Manjarres To: Catalin Marinas Cc: Herbert Xu , Ard Biesheuvel , 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" , Saravana Kannan , kernel-team@android.com Subject: Re: [PATCH 07/10] crypto: Use ARCH_DMA_MINALIGN instead of ARCH_KMALLOC_MINALIGN Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1665596762; 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=iadacU8HjMHZCZhJygxiIG7/MygN7METMFxWBA2IfjE=; b=JU97aaoiOQbbzw/En9piQD416uEo7S7zk1JiZBKdtXs7abIVho7g9I6Yul3uT0OMBLisjt Q71VuAz9AK6gYaGma5gzHPdTzjwfOsjHbfitD2ddOAfNAya9P5myZrL4aNNmo4W/LnXD3L U/Ide+VoBWa0zIj0Pbgm6UAs2MN0VK8= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=Yf1mCOSu; spf=pass (imf25.hostedemail.com: domain of isaacmanjarres@google.com designates 209.85.216.48 as permitted sender) smtp.mailfrom=isaacmanjarres@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1665596762; a=rsa-sha256; cv=none; b=m3JMq4vtTXUCFvlZbngGSCVgdrtpFpmvO3Vdo1doxKHXV+VoXt6EkWeQGImTEa3AyLTpg1 3NGZLmh6ZnX+UeORSUtopk95C17CU1oAmUEQHGpx7Vo4Vb3q19wF+mOfRRrMFHjOApp6iA IefeVdbsH3EwVEgGsFtmdHMVekq8q08= X-Rspam-User: X-Rspamd-Queue-Id: AB6F1A001F X-Stat-Signature: na4za4y9pwwremoc1asswja41a8e7zau Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=Yf1mCOSu; spf=pass (imf25.hostedemail.com: domain of isaacmanjarres@google.com designates 209.85.216.48 as permitted sender) smtp.mailfrom=isaacmanjarres@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspamd-Server: rspam10 X-HE-Tag: 1665596762-584806 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 Fri, Sep 30, 2022 at 07:32:50PM +0100, Catalin Marinas wrote: > I started refreshing the series but I got stuck on having to do bouncing > for small buffers even if when they go through the iommu (and I don't > have the set up to test it yet). For devices that go through the IOMMU, are you planning on adding similar logic as you did in the direct-DMA path to bounce the buffer prior to calling into whatever DMA ops are registered for the device? Also, there are devices with ARM64 CPUs that disable SWIOTLB usage because none of the peripherals that they engage in DMA with need bounce buffering, and also to reclaim the default 64 MB of memory that SWIOTLB uses. With this approach, SWIOTLB usage will become mandatory if those devices need to perform non-coherent DMA transactions that may not necessarily be DMA aligned (e.g. small buffers), correct? If so, would there be concerns that the memory savings we get back from reducing the memory footprint of kmalloc might be defeated by how much memory is needed for bounce buffering? I understand that we can use the "swiotlb=num_slabs" command line parameter to minimize the amount of memory allocated for bounce buffering. If this is the only way to minimize this impact, how much memory would you recommend to allocate for bounce buffering on a system that will only use bounce buffers for non-DMA-aligned buffers? Thanks, Isaac