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 35573C433EF for ; Thu, 21 Apr 2022 13:47:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B40E96B0073; Thu, 21 Apr 2022 09:47:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AF0326B0074; Thu, 21 Apr 2022 09:47:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9926D6B0075; Thu, 21 Apr 2022 09:47:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.27]) by kanga.kvack.org (Postfix) with ESMTP id 8B79F6B0073 for ; Thu, 21 Apr 2022 09:47:49 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 60DAE26F4A for ; Thu, 21 Apr 2022 13:47:49 +0000 (UTC) X-FDA: 79381014258.09.98D8613 Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.187]) by imf31.hostedemail.com (Postfix) with ESMTP id D246A20022 for ; Thu, 21 Apr 2022 13:47:45 +0000 (UTC) Received: from mail-wr1-f54.google.com ([209.85.221.54]) by mrelayeu.kundenserver.de (mreue009 [213.165.67.97]) with ESMTPSA (Nemesis) id 1MiJhW-1oMwSL0qz0-00fU2B for ; Thu, 21 Apr 2022 15:47:47 +0200 Received: by mail-wr1-f54.google.com with SMTP id x18so6816368wrc.0 for ; Thu, 21 Apr 2022 06:47:46 -0700 (PDT) X-Gm-Message-State: AOAM532Zf3GRL919Y0zaovgJXJ4/6/31pgc1a4J3mafA8l9W0CDVHb1x UZxg5WA00ub2wN7F7Sg/AClFX4IydQlJdwftrsY= X-Google-Smtp-Source: ABdhPJxlTD/9qBGDU0e1jg9N9/Rwj2mMB1+npoLE9MkXqDzrZ1/XxNNHg+b6aJOfUifK9Zh8DdyQ/9/LkttN0wyPoV8= X-Received: by 2002:a5d:64a3:0:b0:20a:7931:5b84 with SMTP id m3-20020a5d64a3000000b0020a79315b84mr20340921wrp.407.1650548866522; Thu, 21 Apr 2022 06:47:46 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Arnd Bergmann Date: Thu, 21 Apr 2022 15:47:30 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 07/10] crypto: Use ARCH_DMA_MINALIGN instead of ARCH_KMALLOC_MINALIGN To: Catalin Marinas Cc: Arnd Bergmann , Christoph Hellwig , Ard Biesheuvel , Herbert Xu , Will Deacon , Marc Zyngier , Greg Kroah-Hartman , Andrew Morton , Linus Torvalds , Linux Memory Management List , Linux ARM , Linux Kernel Mailing List , "David S. Miller" Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:AJYkP0J3I6952m/MJ1Lc30VRJh5s64W5nG/lPoGYINe9JtcR9l0 aNectWAs+DmC5DD9ywB7mX+CBzC40H9Vy+pGQxuEnuOKa0y2QJGA1cuEiqVqBMFgLZYn2Re Kl3DHlMdkClT3A1Vfzt1cWUF7/h/Q4mm/Pk2yoQbF6FUphgI7314DbCWesXWFmpPTOi4sFU 6fqvFl6pWgAjd+qy5/o/Q== X-UI-Out-Filterresults: notjunk:1;V03:K0:p4Nrj8bs+1w=:xPCvkr3SCkhcDcFxUNoRs0 f8utjRGIRcIdz0JixAATg4oi+BQFMfnk0Fi3z0v9ZMlRdxUy4na1FrlGA31L+vTIZ9VaBr1W2 XPR4Mf/rbUfcUviePy5qJXSOOhYp01Fe5eHIHIUK5dNtUziXx4i9cxonH//muCIMFZRUp+ZKq Wl65gPFv6+FoRIllYhTyD2P4ywCqUJCNSP/J870cbYeeb/cMF2MFFnpxzP47acnnt0uW7B7u5 b/v9s7AXpsDaFcpME+UHlPs1jSIU06ZLG7pvrAVjJ3aYDbqK04i37SGVLT6bsfD/yU9tq5UHz CQvzUfHfOrQa/QGCyee/RA5XDt84SIfq5rXvKd97BfGMItNdEnlMiLnvWxjqzZYCmCn5gomp6 LswAi6PG1RW8Piqh+gg+adSKaD218IylTq5s9+rn6UxnGbY0fkaZO0xC8TVOPCVL9dLMCR49j Se4bmETXz/2j/yexcfAcCjOLhA+QGT0N2uflWmd0dkbW8rpDv/iNYS23VBYR7skRCGeFHVywF bAPat2r5IP5SbWfupoZj2N2YTMG6duv2hZ/0p5T7Q3Kc89YybkKExiow6RvBQQ32Hrns6no6T OyjXnDRgcjhID4OFFH7AS+OomiNMqXMKJztvUKDfRMyaydzVzbjPLWq6e4QSj3MlryH2v4MWc GSM+uHpjIu/F38jPNoAy8HlvQBPVG0tWT6EPoiLQOEfAbQQh73WBvLyfXPWBbZmr6hizBxLhu /rDbzZvCNhEd7BYPdM4Rc/aOy1rBBtY6EZdAonQi46MCcGzyeD/fDYZkUPTb4hfxvXg1OHldx Ent4AV11fG6s3EfbsfE0BbpBLxaZMcnC35P0EMKnWim4lRPYJ0= Authentication-Results: imf31.hostedemail.com; dkim=none; dmarc=none; spf=none (imf31.hostedemail.com: domain of arnd@arndb.de has no SPF policy when checking 212.227.126.187) smtp.mailfrom=arnd@arndb.de X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: D246A20022 X-Stat-Signature: pbnmi6pimec5s9nidqkspysyeiirb7ui X-HE-Tag: 1650548865-546126 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 Thu, Apr 21, 2022 at 3:25 PM Catalin Marinas wrote: > On Thu, Apr 21, 2022 at 02:28:45PM +0200, Arnd Bergmann wrote: > > We also know that larger slabs are all cacheline aligned, so simply > > comparing the transfer size is enough to rule out most, in this case > > any transfer larger than 96 bytes must come from the kmalloc-128 > > or larger cache, so that works like before. > > There's also the case with 128-byte cache lines and kmalloc-192. Sure, but that's much less common, as the few machines with 128 byte cache lines tend to also have cache coherent devices IIRC, so we'd skip the bounce buffer entirely. > > For transfers <=96 bytes, the possibilities are: > > > > 1.kmalloc-32 or smaller, always needs to bounce > > 2. kmalloc-96, but at least one byte in partial cache line, > > need to bounce > > 3. kmalloc-64, may skip the bounce. > > 4. kmalloc-128 or larger, or not a slab cache but a partial > > transfer, may skip the bounce. > > > > I would guess that the first case is the most common here, > > so unless bouncing one or two cache lines is extremely > > expensive, I don't expect it to be worth optimizing for the latter > > two cases. > > I think so. If someone complains of a performance regression, we can > look at optimising the bounce. I have a suspicion the cost of copying > two cache lines is small compared to swiotlb_find_slots() etc. That is possible, and we'd definitely have to watch out for performance regressions, I'm just skeptical that the cases that suffer from the extra bouncer buffering on 33..64 byte allocations benefit much from having a special case if the 1...32 and 65..96 byte allocations are still slow. Another simpler way to do this might be to just not create the kmalloc-96 (or kmalloc-192) caches, and assuming that any transfer >=33 (or 65) bytes is safe. Arnd