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 D702AC38A2D for ; Wed, 26 Oct 2022 09:58:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7324B8E0002; Wed, 26 Oct 2022 05:58:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6E1F88E0001; Wed, 26 Oct 2022 05:58:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5AA0D8E0002; Wed, 26 Oct 2022 05:58:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 4B9A98E0001 for ; Wed, 26 Oct 2022 05:58:26 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id E256A1C6890 for ; Wed, 26 Oct 2022 09:58:25 +0000 (UTC) X-FDA: 80062650570.02.0F23FE1 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf26.hostedemail.com (Postfix) with ESMTP id 88ECC14000A for ; Wed, 26 Oct 2022 09:58:25 +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 B193461D96; Wed, 26 Oct 2022 09:58:24 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BDF2BC433C1; Wed, 26 Oct 2022 09:58:21 +0000 (UTC) Date: Wed, 26 Oct 2022 10:58:18 +0100 From: Catalin Marinas To: Greg Kroah-Hartman Cc: Linus Torvalds , 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 Subject: Re: [PATCH v2 1/2] mm: slab: Introduce __GFP_PACKED for smaller kmalloc() alignments Message-ID: References: <20221025205247.3264568-1-catalin.marinas@arm.com> <20221025205247.3264568-2-catalin.marinas@arm.com> 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=1666778305; a=rsa-sha256; cv=none; b=HL9BkUJ4MuLGKPRObxxrXYxM/+S0FZkzhLk9ZJsyH1I+tdM4xv9qwOOkIP/UrbFb5OK3zf YCp6tC42r75Cxx4lhZ9ghbyIyzZ3QkBWSWSuq1a6nXBYzWDybBqu9+gG5WinFAWfM2Fssc 3oKGXwZOaw/iocG1JAvF6c/+evRZBBw= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none); spf=pass (imf26.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=1666778305; 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=dwnpT8S/ibcO8UHVdy9utM4vZlkWV2Ipx0B/MEJ4ExE=; b=Xu2aTuiW9vaFf2gOfthBBnXGNXezLGo652f2dIrfoiUmPVctXBiGdfBJIhC+dMdjzz1Z/k 1NlDIVZhyi0+emS+5e7NnTv0Gja0dSSrqSLZ4+Mc4yRZtszyvpuPimb1n/TRExw7jP6SEJ tFNFNgdZYRTxiFaTYC/2GZM3mcX3wN4= X-Rspamd-Queue-Id: 88ECC14000A Authentication-Results: imf26.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none); spf=pass (imf26.hostedemail.com: domain of cmarinas@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=cmarinas@kernel.org X-Rspamd-Server: rspam12 X-Rspam-User: X-Stat-Signature: jy8cwi8girwa75mdzbnsdctrb9czrb4t X-HE-Tag: 1666778305-61321 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 11:49:05AM +0200, Greg Kroah-Hartman wrote: > On Wed, Oct 26, 2022 at 09:39:32AM +0100, Catalin Marinas wrote: > > On Wed, Oct 26, 2022 at 08:39:04AM +0200, Greg Kroah-Hartman wrote: > > > On Tue, Oct 25, 2022 at 09:52:46PM +0100, Catalin Marinas wrote: > > > > By default kmalloc() returns objects aligned to ARCH_KMALLOC_MINALIGN. > > > > This can be somewhat large on architectures defining ARCH_DMA_MINALIGN > > > > (e.g. 128 on arm64) and significant memory is wasted through small > > > > kmalloc() allocations. > > > > > > > > Reduce the minimum alignment for kmalloc() to the default > > > > KMALLOC_MIN_SIZE (8 for slub, 32 for slab) but align the > > > > requested size to the bigger ARCH_KMALLOC_MINALIGN unless a newly added > > > > __GFP_PACKED flag is passed. With this gfp flag, the alignment is > > > > reduced to KMALLOC_PACKED_ALIGN, at least sizeof(unsigned long long). > > > > > > Can memory allocated with __GFP_PACKED be sent to DMA controllers? > > > > > > If not, you should say that somewhere here or I'm going to get a bunch > > > of patches trying to add this flag to tiny USB urb allocations (where we > > > allocate 8 or 16 bytes) that is then going to fail on some hardware. > > > > Good point, I'll add a comment. > > > > We can also add a check to the DMA API when debugging is enabled, > > something like WARN_ON_ONCE(ksize(ptr) < cache_line_size()) for > > non-coherent devices. > > It's not the size of the object that matters, it's the alignment, right? > So shouldn't the check be simpler to just look at the alignment of the > pointer which should be almost "free"? It's the alignment of the start (easily checked) but also the end. For small urb allocations, we need to know that they came from a slab page where there's nothing in the adjacent bytes before the next cache line. It would have been nice if the DMA API was called with both start and size aligned but that's not the case. I think such check would fail even for larger buffers like network packets. -- Catalin 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 A31A0C38A2D for ; Wed, 26 Oct 2022 09:59:30 +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=FSe/bKqIzXM2s4qOreUgCQmxfWObYbQOzyquPO/+BI4=; b=b6nXFiMX5Kn1QK G6FIHi4oOZJgOufODrkMjHQEwdyMO1gMtB7/7o9ZRr2wV1IoCV5q//BZFfdLM8k+tKI3i0TYRLrFX e07xGjD29aNILZjG1+Br0lYMIy62LN+27h9KDek5UoPN0tIIJEOLu2wbxTl6Or5x/b9l18igxIP08 noFLZUE+yG3Bz2o4IX+SWTWZintVFErjom/VyanUoXtq8123msK722NtSh5ueb98S798TlY3UBS1n 4NZgo7F64mBu+VM260vMIjk2uULqHmJ1xMC0WG3x3jQcwIcIeK9rodKefoJdcROTADvtI9g+u3k2Z bPIH65bNEn/j9hTCgl1A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ondB7-008shA-GO; Wed, 26 Oct 2022 09:58:29 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1ondB3-008sfx-HH for linux-arm-kernel@lists.infradead.org; Wed, 26 Oct 2022 09:58:28 +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 B193461D96; Wed, 26 Oct 2022 09:58:24 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BDF2BC433C1; Wed, 26 Oct 2022 09:58:21 +0000 (UTC) Date: Wed, 26 Oct 2022 10:58:18 +0100 From: Catalin Marinas To: Greg Kroah-Hartman Cc: Linus Torvalds , 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 Subject: Re: [PATCH v2 1/2] mm: slab: Introduce __GFP_PACKED for smaller kmalloc() alignments Message-ID: References: <20221025205247.3264568-1-catalin.marinas@arm.com> <20221025205247.3264568-2-catalin.marinas@arm.com> 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-20221026_025826_970670_043FF7D0 X-CRM114-Status: GOOD ( 29.12 ) 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 Wed, Oct 26, 2022 at 11:49:05AM +0200, Greg Kroah-Hartman wrote: > On Wed, Oct 26, 2022 at 09:39:32AM +0100, Catalin Marinas wrote: > > On Wed, Oct 26, 2022 at 08:39:04AM +0200, Greg Kroah-Hartman wrote: > > > On Tue, Oct 25, 2022 at 09:52:46PM +0100, Catalin Marinas wrote: > > > > By default kmalloc() returns objects aligned to ARCH_KMALLOC_MINALIGN. > > > > This can be somewhat large on architectures defining ARCH_DMA_MINALIGN > > > > (e.g. 128 on arm64) and significant memory is wasted through small > > > > kmalloc() allocations. > > > > > > > > Reduce the minimum alignment for kmalloc() to the default > > > > KMALLOC_MIN_SIZE (8 for slub, 32 for slab) but align the > > > > requested size to the bigger ARCH_KMALLOC_MINALIGN unless a newly added > > > > __GFP_PACKED flag is passed. With this gfp flag, the alignment is > > > > reduced to KMALLOC_PACKED_ALIGN, at least sizeof(unsigned long long). > > > > > > Can memory allocated with __GFP_PACKED be sent to DMA controllers? > > > > > > If not, you should say that somewhere here or I'm going to get a bunch > > > of patches trying to add this flag to tiny USB urb allocations (where we > > > allocate 8 or 16 bytes) that is then going to fail on some hardware. > > > > Good point, I'll add a comment. > > > > We can also add a check to the DMA API when debugging is enabled, > > something like WARN_ON_ONCE(ksize(ptr) < cache_line_size()) for > > non-coherent devices. > > It's not the size of the object that matters, it's the alignment, right? > So shouldn't the check be simpler to just look at the alignment of the > pointer which should be almost "free"? It's the alignment of the start (easily checked) but also the end. For small urb allocations, we need to know that they came from a slab page where there's nothing in the adjacent bytes before the next cache line. It would have been nice if the DMA API was called with both start and size aligned but that's not the case. I think such check would fail even for larger buffers like network packets. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel