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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id A2CCBC433FE for ; Sun, 16 Oct 2022 21:39:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=/6Q0SMIqMRCY99xwmh0yrlJ92ixmUM6W5qGaS/rdsMk=; b=MyLOrfQSiKvLfe XbxOajxhYziUoXtSo6nYNI7y81WgIumGXeDTD5JPqoa+yLgSnZMBeqewrdP8iMiJVZ7/GJmVvrfbB Pks2GJfMVtses6igS6hbIaibzw+uu26w4VMXYUP943PYDt4rUQT/4ZzNz++/QvawHJBt8AKzXyNwe bLxa+aKxOzdgnAohYpwoyci+hcvRjsFELMSSzXmphRt24wm3GVDwlo/BwIByWqPgvUbG0uLy3Ul7T Ud/v32ANWqOhvdZ4lFbYQA/mRzHrsE4ybSyX9aL6pTWQRdmf3uhzwbNVy/H+nu4qh3uCGRuHTpdQT aVvEzpObryqBSUCWX1Zg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1okBKb-0047gE-9W; Sun, 16 Oct 2022 21:38:01 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1okBKX-0047c6-MJ for linux-arm-kernel@lists.infradead.org; Sun, 16 Oct 2022 21:37:59 +0000 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-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221016_143757_917386_3B361C5A X-CRM114-Status: GOOD ( 19.29 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel