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 923F3C433FE for ; Fri, 15 Apr 2022 06:04:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EA52D6B0071; Fri, 15 Apr 2022 02:04:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E54CD6B0073; Fri, 15 Apr 2022 02:04:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D1C866B0074; Fri, 15 Apr 2022 02:04:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.a.hostedemail.com [64.99.140.24]) by kanga.kvack.org (Postfix) with ESMTP id C2FFC6B0071 for ; Fri, 15 Apr 2022 02:04:11 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 954AF260A3 for ; Fri, 15 Apr 2022 06:04:11 +0000 (UTC) X-FDA: 79358073102.01.662E3FA Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf28.hostedemail.com (Postfix) with ESMTP id D0E05C0005 for ; Fri, 15 Apr 2022 06:04:10 +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 ams.source.kernel.org (Postfix) with ESMTPS id EEE85B8282C for ; Fri, 15 Apr 2022 06:04:08 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B4268C385AD for ; Fri, 15 Apr 2022 06:04:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1650002647; bh=CfFBFrsOrM1D6QuDY5JL6c2VKraxHdnJ8iQxVuMosgw=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=rQq1sZ4J1sg22E9oqdhg4EJn8neJLzquXI+ZjaLeifOERti0Wc+sHK1ca9AEuAedm amy5K2gapC1d/YsBm8lKYZa4FJlvxfvg2uMYXZW+FECTSlN5rRK7n46i4eYJiT8dUP NtiYz25I/4SLS+ajSx8TMqQAykzYQpMyTAcuLWze4mw13G0A4DVOegWZUDW0M2S/tI uzeS54JMWY8wDnTklfomrz11JZpKfoakRJTc9X4u3F2pgMPd0kcfv1uydJuck6C97z CHIcWL2MuEdFh32B9IwZ2OpEt+7syLJujcZiPCe8uAwUQ8XxGWdZKvFcfl9sbse5l2 wrEusSELhVbcw== Received: by mail-oi1-f173.google.com with SMTP id b188so7588445oia.13 for ; Thu, 14 Apr 2022 23:04:07 -0700 (PDT) X-Gm-Message-State: AOAM532QfWrGX0wXGEBSzEx+3hbRTaJFghf3g8yOd22a8ZPTrI2QD1d5 VTFm2gZtgjce+T8CY2Cl1avtWSXPEeLx0HgzOQI= X-Google-Smtp-Source: ABdhPJz2xwpnXQaQcae68WnDv78hot7NwSWZe+t2TtHgLprVUTWzxwQZi9+tdzNS0HtyfFS5Ou/0nwNdizG5ZHLSuiQ= X-Received: by 2002:a05:6808:1596:b0:2f7:5d89:eec7 with SMTP id t22-20020a056808159600b002f75d89eec7mr1017334oiw.228.1650002646826; Thu, 14 Apr 2022 23:04:06 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ard Biesheuvel Date: Fri, 15 Apr 2022 08:03:54 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 07/10] crypto: Use ARCH_DMA_MINALIGN instead of ARCH_KMALLOC_MINALIGN To: Linus Torvalds Cc: Catalin Marinas , Herbert Xu , Will Deacon , Marc Zyngier , Arnd Bergmann , Greg Kroah-Hartman , Andrew Morton , Linux Memory Management List , Linux ARM , Linux Kernel Mailing List , "David S. Miller" Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Queue-Id: D0E05C0005 X-Stat-Signature: mn4id17ps15cemcko6k9p7f97bpp19ki Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=rQq1sZ4J; spf=pass (imf28.hostedemail.com: domain of ardb@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=ardb@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-Rspamd-Server: rspam01 X-HE-Tag: 1650002650-348104 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, 15 Apr 2022 at 00:26, Linus Torvalds wrote: > > On Thu, Apr 14, 2022 at 12:49 PM Catalin Marinas > wrote: > > > > It's a lot worse, ARCH_KMALLOC_MINALIGN is currently 128 bytes on arm64. > > I want to at least get it down to 64 with this series while preserving > > the current kmalloc() semantics. > > So here's a thought - maybe we could do the reverse of GFP_DMA, and > add a flag to the places that want small allocations and know they > don't need DMA? > > Because even 64 bytes is _huge_ for those small allocations. And 128 > bytes is just insane. > > Maybe we don't have a ton of them, but I just checked my desktop, and > if my laptop had 17k 8-byte allocation, on my desktop it's currently > sitting at 43k of them. And I've got a lot of 16- and 32-byte ones > too: > > kmalloc-32 51529 51712 32 128 1 : > kmalloc-16 45056 45056 16 256 1 : > kmalloc-8 43008 43008 8 512 1 : > > Don't ask me what they are. It's probably fairly easy to find out, and > it's probably something silly like sysfs private pointer data or > whatever. > > If I did my math right, with a 128-byte minimum allocation, that is > 16MB of wasted memory. > > Yeah, yeah, I've got 64GB or RAM in this thing, and there are things > that take a lot more memory than the above (mem_map etc), and 64MB is > peanuts at just 0.1% of RAM. > Actually, I think the impact on D-cache efficiency is a much bigger concern, although I don't have any data to back that up. On arm64, every 8 byte allocation takes up an entire cacheline, pushing out other data that we could meaningfully keep there. And the doubling to 128 that is unnecessary on most arm64 systems probably has an additional negative effect, as it means those allocations are heavily skewed to use even indexes into the cache sets, causing extra contention. > Maybe nobody cares. But I really feel bad about that kind of egregious > waste. The mem_map[] array may be big, it may use 1.5% of the memory I > have, but at least it *does* something. > > And it could be that if I have 150k of those smallish allocations, a > server with lots of active users might have millions. Not having > looked at where they come from, maybe that isn't the case, but it > *might* be. > > Maybe adding something like a > > static int warn_every_1k = 0; > WARN_ON(size < 32 && (1023 & ++warn_every_1k)); > > to kmalloc() would give us a statistical view of "lots of these small > allocations" thing, and we could add GFP_NODMA to them. There probably > aren't that many places that have those small allocations, and it's > certainly safer to annotate "this is not for DMA" than have the > requirement that all DMA allocations must be marked. > > Then just teach kmalloc() something like > > align = (gfp_flags & __GFP_NODMA) ? 8 : 128; > > on arm. > Sounds like a lot of churn as well, tbh. But perhaps there are a few hot spots that we can fix that would alleviate the bulk of the issue, who knows?