Received: by 2002:a05:6358:9144:b0:117:f937:c515 with SMTP id r4csp1800282rwr; Fri, 28 Apr 2023 01:55:33 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ6QJXKLMBG5wVfR/qsQn5jphlBVKHLXPB9qzQ3ruisFkFtcKxYMJ5QC7fcJO0UXaad5wtbs X-Received: by 2002:a17:902:ce83:b0:1a1:d54b:71df with SMTP id f3-20020a170902ce8300b001a1d54b71dfmr6045610plg.0.1682672133206; Fri, 28 Apr 2023 01:55:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1682672133; cv=none; d=google.com; s=arc-20160816; b=bcaflT9ruafpg1tgmzh/4BBRxe5rE4KNLCwMEc2+fPhTf/vLj6flalUNT2DZlAUa9V JYtthaE9K0kqhI9qENw/zu12Px60TatVLFUBx+SWZb26WAUFqC4lEvIReGijvO+Kw2ql wwI+KWP9c6Odr04EjvV5fkoNPCQjc9R3Ush7QQ/ly6UGQu56fWCpIEFOpz3sLjBEJJ1W 4rz9hHRy//MxaGzBreI9jvApXBuRMswrH1jyYEYQrvxynG6mcDBfREzoQ322TTsn5hb2 c1+AVmmai7ux9VUPLD5saewJHUPZcD/Un7wMrsqz78+LgCXBk2zK+yxF2PB0LvPKGpar eG6w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=pL4Xsln7CoA4UJTPrm8Ceoo9nwMvFKVDs7triguts9c=; b=ADyqyTD/FV1OougLpO+sDqgXp4pGt/M82AADMCxiC6kpCnUm6fwBUvxMxSfrMp4AGU 85SawnOz58J979XAkfHNxRz225ohx+/IHhDsX8mrpMPQVFD6mdW18E16GfUskHyrjljo IJ/AHUGGNKMEGTITIGzLSN10MdjvCRwfQZrNaj6YiLvcSYDhFyLPVm/h8jo890OyrbNJ AfwV7LRE1fEdz9aEprwaq6ojCC7d970A24Z8wGpDzVaYXFANLLcsU8eTew58bTaIOIxH I9RPAg+NqB+FCbVoltTqZeUAdhU3oWQeXdhEbKbepEQ7EMuqfMcHmRFirFD52wnNzU5h XkhQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@fireburn-co-uk.20221208.gappssmtp.com header.s=20221208 header.b=iOgcvluJ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id w12-20020a170902e88c00b001a656596b9esi22327222plg.608.2023.04.28.01.55.20; Fri, 28 Apr 2023 01:55:33 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@fireburn-co-uk.20221208.gappssmtp.com header.s=20221208 header.b=iOgcvluJ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345317AbjD1IzQ (ORCPT + 99 others); Fri, 28 Apr 2023 04:55:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60588 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345550AbjD1Iyy (ORCPT ); Fri, 28 Apr 2023 04:54:54 -0400 Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 22F375BB9 for ; Fri, 28 Apr 2023 01:54:22 -0700 (PDT) Received: by mail-wm1-x335.google.com with SMTP id 5b1f17b1804b1-3f09b4a1584so65697635e9.2 for ; Fri, 28 Apr 2023 01:54:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fireburn-co-uk.20221208.gappssmtp.com; s=20221208; t=1682672030; x=1685264030; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=pL4Xsln7CoA4UJTPrm8Ceoo9nwMvFKVDs7triguts9c=; b=iOgcvluJ5NlwY+G2e3qRzuy+4lPMNksSVQlm7/f+23M3xismiwP81z2CjEF983Rtzz hfAKd9oi1J+uyQpmFVfLIOEh9YTNZ5tvHlChRgsM9K/WaTIlJqz8bp6UWXacz0IpIhbn MekpkdSne5knaH4YfrOPUlQWNE3hHOG3i/jRykdfxxBJvW111nbs+cbjdVtSpjH4vR+x wrNyi2FQ8LRBY+F2hkQvMk5UGNZnHkcTuU8xIitWijrjoV3Vjr2tZFLEIb3jEbbgVgO1 cqLKVJDm/+qbcilvevaTFEhIbxJSbqS/comyiqIQrMTlC8ja8cADbGUVrANh0K9SGGZN VJeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682672030; x=1685264030; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=pL4Xsln7CoA4UJTPrm8Ceoo9nwMvFKVDs7triguts9c=; b=LCHnSaU2mSfdLraQQ6jyRR2xBf9YrFNtOEAsU1VWFzKY/jsCmVd5fOarDL5EhID2B+ HPlExfiYdL1peiZe7dmLH0tVXz9vytPeuwlJsp4PZV+Hl8Dc1/fwAoY7zBwDNKZCfBAp 5GvQAviMK2SK67Jb7rQiTHSTdtCokFUtHtKPeNZov0gdbgwqlD20zRHt4ijwZCs25pIG s0B6XrtMr0JJbDLxBidwJPHhS3drCBxcp1Sx76o3WcDFIeAxr4ipx72PDN9yr9W3qN4N W4hu/AU6YNadsP/5V6BGyjLf9kXwgM7u/1qj+pPllVJTiW+62f1Quo7WuXTZHTZlM8I/ dHjw== X-Gm-Message-State: AC+VfDyJnVKvIpybZRxcMOnmhWfoIfru//0WCKHCujZUwDcTZr01BZE5 GC364FEXOZ8IR4jgDkZZGTXmxWJolDhzyBmIKH8Lyw== X-Received: by 2002:a7b:c5c6:0:b0:3f0:8fb3:24ea with SMTP id n6-20020a7bc5c6000000b003f08fb324eamr3436522wmk.9.1682672029706; Fri, 28 Apr 2023 01:53:49 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Mike Lothian Date: Fri, 28 Apr 2023 09:53:38 +0100 Message-ID: Subject: Re: [PATCH v2 0/7] Allow dynamic allocation of software IO TLB bounce buffers To: Petr Tesarik Cc: Jonathan Corbet , Greg Kroah-Hartman , "Rafael J. Wysocki" , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Daniel Vetter , Christoph Hellwig , Marek Szyprowski , Robin Murphy , Borislav Petkov , "Paul E. McKenney" , Catalin Marinas , Will Deacon , Zhen Lei , Randy Dunlap , Damien Le Moal , Kim Phillips , "Steven Rostedt (Google)" , Muchun Song , Ondrej Zary , "Jason A. Donenfeld" , Petr Tesarik , Hans de Goede , Dan Williams , Andy Shevchenko , Kees Cook , Thomas Gleixner , Won Chung , "open list:DOCUMENTATION" , open list , "open list:DRM DRIVERS" , "open list:DMA MAPPING HELPERS" , petr@tesarici.cz, Kefeng Wang , Roberto Sassu Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE, T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 19 Apr 2023 at 11:05, Petr Tesarik wrote: > > From: Petr Tesarik > > The goal of my work is to provide more flexibility in the sizing of > SWIOTLB. > > The software IO TLB was designed with these assumptions: > > 1. It would not be used much, especially on 64-bit systems. > 2. A small fixed memory area (64 MiB by default) is sufficient to > handle the few cases which require a bounce buffer. > 3. 64 MiB is little enough that it has no impact on the rest of the > system. > > First, if SEV is active, all DMA must be done through shared > unencrypted pages, and SWIOTLB is used to make this happen without > changing device drivers. The software IO TLB size is increased to > 6% of total memory in sev_setup_arch(), but that is more of an > approximation. The actual requirements may vary depending on the > amount of I/O and which drivers are used. These factors may not be > know at boot time, i.e. when SWIOTLB is allocated. > > Second, other colleagues have noticed that they can reliably get > rid of occasional OOM kills on an Arm embedded device by reducing > the SWIOTLB size. This can be achieved with a kernel parameter, but > determining the right value puts additional burden on pre-release > testing, which could be avoided if SWIOTLB is allocated small and > grows only when necessary. > > Changes from v1-devel-v7: > - Add comments to acquire/release barriers > - Fix whitespace issues reported by checkpatch.pl > > Changes from v1-devel-v6: > - Provide long description of functions > - Fix kernel-doc (Returns: to Return:) > - Rename __lookup_dyn_slot() to lookup_dyn_slot_locked() > > Changes from RFC: > - Track dynamic buffers per device instead of per swiotlb > - Use a linked list instead of a maple tree > - Move initialization of swiotlb fields of struct device to a > helper function > - Rename __lookup_dyn_slot() to lookup_dyn_slot_locked() > - Introduce per-device flag if dynamic buffers are in use > - Add one more user of DMA_ATTR_MAY_SLEEP > - Add kernel-doc comments for new (and some old) code > - Properly escape '*' in dma-attributes.rst > > Petr Tesarik (7): > swiotlb: Use a helper to initialize swiotlb fields in struct device > swiotlb: Move code around in preparation for dynamic bounce buffers > dma-mapping: introduce the DMA_ATTR_MAY_SLEEP attribute > swiotlb: Dynamically allocated bounce buffers > swiotlb: Add a boot option to enable dynamic bounce buffers > drm: Use DMA_ATTR_MAY_SLEEP from process context > swiotlb: per-device flag if there are dynamically allocated buffers > > .../admin-guide/kernel-parameters.txt | 6 +- > Documentation/core-api/dma-attributes.rst | 10 + > drivers/base/core.c | 4 +- > drivers/gpu/drm/drm_gem_shmem_helper.c | 2 +- > drivers/gpu/drm/drm_prime.c | 2 +- > include/linux/device.h | 12 + > include/linux/dma-mapping.h | 6 + > include/linux/swiotlb.h | 54 ++- > kernel/dma/swiotlb.c | 382 ++++++++++++++++-- > 9 files changed, 443 insertions(+), 35 deletions(-) > > -- > 2.25.1 > Hi Is this a potential fix for https://bugzilla.kernel.org/show_bug.cgi?id=217310 where I'm manually setting bigger buffers to keep my wifi working? Thanks Mike