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 81CA3C433EF for ; Fri, 15 Apr 2022 11:09:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 051006B0071; Fri, 15 Apr 2022 07:09:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 001736B0073; Fri, 15 Apr 2022 07:09:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E0BB86B0074; Fri, 15 Apr 2022 07:09:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.25]) by kanga.kvack.org (Postfix) with ESMTP id D34C86B0071 for ; Fri, 15 Apr 2022 07:09:35 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id BFAA023FCD for ; Fri, 15 Apr 2022 11:09:35 +0000 (UTC) X-FDA: 79358842710.20.1579BBB Received: from mout.kundenserver.de (mout.kundenserver.de [217.72.192.74]) by imf29.hostedemail.com (Postfix) with ESMTP id F1A22120006 for ; Fri, 15 Apr 2022 11:09:34 +0000 (UTC) Received: from mail-wr1-f52.google.com ([209.85.221.52]) by mrelayeu.kundenserver.de (mreue109 [213.165.67.113]) with ESMTPSA (Nemesis) id 1MirfG-1oBLGT1i3o-00erq7 for ; Fri, 15 Apr 2022 13:09:33 +0200 Received: by mail-wr1-f52.google.com with SMTP id t1so10301559wra.4 for ; Fri, 15 Apr 2022 04:09:33 -0700 (PDT) X-Gm-Message-State: AOAM531M8GAII+BZIi+/9sVJ5WxTkl7pGVVSRMCprRvLAGgS8jEp6FZg kvuk2wYX9PUqO7zVw88Hb3jCVXq3ihx1AG6tPTU= X-Google-Smtp-Source: ABdhPJyj3r7FEz5sXf6C3O9OOPQLQ/zV1cGeI/CnsNj84hy2M5ncBvkKZ6ruVU3zwgf+xJtInPaRa4Ahl7zJs9RlMu0= X-Received: by 2002:a5d:64a3:0:b0:20a:7931:5b84 with SMTP id m3-20020a5d64a3000000b0020a79315b84mr3630251wrp.407.1650020972755; Fri, 15 Apr 2022 04:09:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Arnd Bergmann Date: Fri, 15 Apr 2022 13:09:15 +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 , Ard Biesheuvel , 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-Provags-ID: V03:K1:D4aOazaCHBtOliHO9uOMog8+Ca/qGpM5e+ymEXiiaIS3DySpSDu vx94itIuXkb7Ft3F2MbuOTXwLGj8xgNFZhknImq76icOEd0EXsU73pLjvfVL6awp/W0SsjS ovcScknXfGEXYTIBchEETYCHfYWIjmzAbkJb6WReneFAeB6YpBfJ0oOt+5hotH0HpQiCo+f arUyAMQM7Lict9ZXsFmdg== X-UI-Out-Filterresults: notjunk:1;V03:K0:MDHnhyOH5yE=:RZH6qPakLrG5tipZrLxk4r or7b1GlQx/WpuhZOCDNgwAW5OPBDL/XfI4PZ/XvpzbopgpQ+z2wKRKCga4uhDtBI2JftXmhmM nmxwwHTTVzf1x0y1Po3UHExM70GOqi3WMwGi4GWp5ZqE3/RpnCOunD6tCXuBn5RtA04RTxrH/ 78TikuJyGkhekd3xPq8w5P6dgInzJDC9wCWjOdnW26DQoB/8xqOMkLfDGaJTlHTi8LhwnV8my tC6mFyYvp6EZmvBxOz+hJWPqP+RoyAHAwEKcPq3UYDVRPakWA13uf9nf+cwy4WbedGWsXeKsV Kl9pVMppdbi5VEYVZkD+SGwFV/IYdAECF8kN+EHqeS3uueJRu/t6f3CulI8O2sn15vniunuqJ p8CS5L7sVtkTsfSdZ6A4Kq+cUA46ucLy37KNYHQsEHK/mvP1k2+UFEp213G7S+3LcxCZRHjIN SqnCHv1sAMAdIQC4PGj377A1wWsDEwzhZwyPFQ0ksQMuqRkk/HXdBytFK+z35e1wW7fkDOEfB 2U0+wCYEls2U+qls7r8R/4pNHSFzX3w0cVYX4hFtub1CVZcK9Cz2sFjaFeIxeBaAzhHemxld0 FOjEMMfafnSVEXTLrB0/xyKe6KPQ0cWeEeKw2JM0Wi+hZsTHLMA5hBgu2Pg3Gux+Pzir9FKMM obxEdfAq1i8uy6Ej2kCP8hsdoBTWU0amTXJdINkdmKwwq8uwwR+Pw4o/zaVVFFQKyopc= X-Stat-Signature: o5jj9d1ja91j86yzkg9654jix1i9x83m X-Rspam-User: Authentication-Results: imf29.hostedemail.com; dkim=none; dmarc=none; spf=none (imf29.hostedemail.com: domain of arnd@arndb.de has no SPF policy when checking 217.72.192.74) smtp.mailfrom=arnd@arndb.de X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: F1A22120006 X-HE-Tag: 1650020974-889212 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, Apr 15, 2022 at 12:25 AM Linus Torvalds wrote: > > > 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. I think finding out the allocations is one of the most common examples for ftrace. I followed the instructions from https://www.kernel.org/doc/Documentation/trace/events.txt to show me a histogram of all allocations under 256 bytes, which (one kernel compile later) gives me something like $echo 'hist:key=call_site.sym-offset:val=bytes_req:sort=bytes_req.descending if bytes_req<256' > \ /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger $ make -skj30 ... $ head /sys/kernel/debug/tracing/events/kmem/kmalloc/hist { call_site: [ffffffffc04e457f] btrfs_delete_delayed_dir_index+0xbf/0x1e0 [btrfs] } hitcount: 146914 bytes_req: 16454368 { call_site: [ffffffffbbe601a3] generic_file_buffered_read+0x463/0x4a0 } hitcount: 98187 bytes_req: 14906232 { call_site: [ffffffffc0497b81] btrfs_buffered_write+0x131/0x7e0 [btrfs] } hitcount: 156513 bytes_req: 10038544 { call_site: [ffffffffc05125c9] btrfs_alloc_block_rsv+0x29/0x60 [btrfs] } hitcount: 155044 bytes_req: 8682464 { call_site: [ffffffffbbfe7272] kernfs_fop_open+0xc2/0x290 } hitcount: 38764 bytes_req: 5892128 { call_site: [ffffffffbbfb6ea2] load_elf_binary+0x242/0xed0 } hitcount: 58276 bytes_req: 3729664 { call_site: [ffffffffc04b52d0] __btrfs_map_block+0x1f0/0xb60 [btrfs] } hitcount: 29289 bytes_req: 3521656 { call_site: [ffffffffbbf7ac7e] inotify_handle_inode_event+0x7e/0x210 } hitcount: 61688 bytes_req: 2986992 { call_site: [ffffffffbbf2fa35] alloc_pipe_info+0x65/0x230 } hitcount: 13139 bytes_req: 2312464 { call_site: [ffffffffbc0cd3ec] security_task_alloc+0x9c/0x100 } hitcount: 60475 bytes_req: 2177100 { call_site: [ffffffffbc0cd5f6] security_prepare_creds+0x76/0xa0 } hitcount: 266124 bytes_req: 2128992 { call_site: [ffffffffbbfe710e] kernfs_get_open_node+0x7e/0x120 } hitcount: 38764 bytes_req: 1860672 { call_site: [ffffffffc04e1fbd] btrfs_alloc_delayed_item+0x1d/0x50 [btrfs] } hitcount: 11859 bytes_req: 1833383 { call_site: [ffffffffc046595d] split_item+0x8d/0x2e0 [btrfs] } hitcount: 14049 bytes_req: 1716288 { call_site: [ffffffffbbfb6dbc] load_elf_binary+0x15c/0xed0 } hitcount: 58276 bytes_req: 1631728 { call_site: [ffffffffbbf40e79] __d_alloc+0x179/0x1f0 } hitcount: 24814 bytes_req: 1280649 { call_site: [ffffffffbbf5203f] single_open+0x2f/0xa0 } hitcount: 34541 bytes_req: 1105312 { call_site: [ffffffffc047ad0a] btrfs_wq_submit_bio+0x4a/0xe0 [btrfs] } hitcount: 7746 bytes_req: 1053456 { call_site: [ffffffffbc519e95] xhci_urb_enqueue+0xf5/0x3c0 } hitcount: 5511 bytes_req: 484968 { call_site: [ffffffffc0482935] btrfs_opendir+0x25/0x70 [btrfs] } hitcount: 60245 bytes_req: 481960 { call_site: [ffffffffc04c44ff] overwrite_item+0x1cf/0x5c0 [btrfs] } hitcount: 7378 bytes_req: 364305 { call_site: [ffffffffc04c4514] overwrite_item+0x1e4/0x5c0 [btrfs] } hitcount: 7378 bytes_req: 364305 { call_site: [ffffffffc04e207f] btrfs_wq_run_delayed_node+0x2f/0x80 [btrfs] } hitcount: 3427 bytes_req: 356408 { call_site: [ffffffffbbe7e96d] shmem_symlink+0xbd/0x250 } hitcount: 5169 bytes_req: 242943 { call_site: [ffffffffc03e0526] hid_input_field+0x56/0x290 [hid] } hitcount: 11004 bytes_req: 175760 I think these are all safe for the GFP_NODMA approach you suggest, maybe not the xhci_urb_enqueue one. Arnd