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 A596CC4332F for ; Sun, 16 Oct 2022 21:37:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 94A346B0072; Sun, 16 Oct 2022 17:37:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8F947900002; Sun, 16 Oct 2022 17:37:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7C1E88E0001; Sun, 16 Oct 2022 17:37:57 -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 695116B0072 for ; Sun, 16 Oct 2022 17:37:57 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 205C9A025B for ; Sun, 16 Oct 2022 21:37:57 +0000 (UTC) X-FDA: 80028125394.23.D1B805F Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf17.hostedemail.com (Postfix) with ESMTP id AF4CC40030 for ; Sun, 16 Oct 2022 21:37:56 +0000 (UTC) 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 BFFC760DFE; Sun, 16 Oct 2022 21:37:55 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 85814C433C1; Sun, 16 Oct 2022 21:37:52 +0000 (UTC) Date: Sun, 16 Oct 2022 22:37:48 +0100 From: Catalin Marinas To: Linus Torvalds Cc: Saravana Kannan , 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" , 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-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1665956276; a=rsa-sha256; cv=none; b=AI/TRQ70U1fntTTuS1OmV0JV/V2mIgwFLrTjkx4j25l4p7yeeO1zkVAAnRc21mwPDF0p6X In5qGrTnOF6uvz5gAgfCOzGZJ050+/Gv9Zx1P4DigIr5mlKrr6l18hVZ8GnzpwK8yrzizQ lGZSiQOa0KgkiKLd7Ih3QH4z/kYX0Tc= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none); spf=pass (imf17.hostedemail.com: domain of cmarinas@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=cmarinas@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1665956276; 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; bh=q0e6wRiWYtxNrMSKQdHqBCY+m8ww2a8PbforbV0yOtg=; b=etDsILtfhz+iPsLSeJl/Y+ExG6BnQnxLPBXO832wl7bdCH21fSVzu69UDZZSg3EykEKMK0 AOoitGLLv7GIccpAytt2K4OHWv0X8xRxcp3cmbTbZ9hYQsj3Wpk84xIvUmIaK668oqEH8K qAOKeKHGWryU0ornAwEPuim/xO27bQU= X-Rspam-User: Authentication-Results: imf17.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none); spf=pass (imf17.hostedemail.com: domain of cmarinas@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=cmarinas@kernel.org X-Stat-Signature: qcdj3xg3fnb1bsdsskz1femqzu3nj6o4 X-Rspamd-Queue-Id: AF4CC40030 X-Rspamd-Server: rspam10 X-HE-Tag: 1665956276-669609 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, Oct 14, 2022 at 01:44:25PM -0700, Linus Torvalds wrote: > On Fri, Oct 14, 2022 at 1:24 PM Saravana Kannan wrote: > > Agreed. Even allowing a 64-byte kmalloc cache on a system with a > > 64-byte cacheline size saves quite a bit of memory. > > Well, the *really* trivial thing to do is to just say "if the platform > is DMA coherent, just allow any size kmalloc cache". And just > consciously leave the broken garbage behind. The problem is we don't have a reliable way to tell whether the platform is DMA-coherent. The CPU IDs don't really say much and in most cases it's a property of the interconnect/bus and device. We describe the DMA coherency in DT or ACPI and the latter is somewhat better as it assumes coherent by default. But for DT, not having a 'dma-coherent' property means non-coherent DMA (or no DMA at all). We can't even tell whether the device is going to do any DMA, arch_setup_dma_ops() is called even for devices like the PMU. We could look into defining new properties (e.g. "no-dma") and adjust the DTs but we may also have late probed devices, long after the slab allocator was initialised. A big 'dma-coherent' property on the top node may work but most Android systems won't benefit from this (your laptop may, I haven't checked). I think the best bet is still either (a) bounce for small sizes or (b) a new GFP_NODMA/PACKED/etc. flag for the hot small allocations. (a) is somehow more universal but lots (most) Android devices are deployed with no swiotlb buffer as the vendor knows the device needs and don't need extra buffer waste. Not sure how reliable it would be to trigger another slab allocation on the dma_map_*() calls for the bounce (it may need to be GFP_ATOMIC). Option (b) looks more appealing on such systems, though a lot more churn throughout the kernel. -- Catalin