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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6FFF1C77B61 for ; Fri, 28 Apr 2023 08:55:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345702AbjD1IzQ (ORCPT ); Fri, 28 Apr 2023 04:55:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60924 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345398AbjD1Iyz (ORCPT ); Fri, 28 Apr 2023 04:54:55 -0400 Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 645C45FE0 for ; Fri, 28 Apr 2023 01:54:23 -0700 (PDT) Received: by mail-wm1-x330.google.com with SMTP id 5b1f17b1804b1-3f178da21b5so65780545e9.3 for ; Fri, 28 Apr 2023 01:54:23 -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=WG/3NPsHGvhl5qnf4rzq/ItoLPN4OHTgAYH20SzvLIWMYOIU9bR2q7NxQlOrw4IPvo mFL+pu07/3u1sDTlP9CPDRJqhtONZ27Ln6Wq15cidhrqWCzojkTKPUniyhxjMi4jmd7U nmPqTDgUPkJv4Ugc3JjLY0v7y/Ib3g6zHW/pbK/4diMPuj2PXViYyVlaxk3Tma47WQcF V2IxWxVYS8AJEqKUxD8xqjthE+BeQ737300c37yJFXeFCZ1VEUnfC0m28Kcly4o4bYN8 gCFLxGb+AtFrc9SAQE5JbzP7NrcaCNfP4XwDyRX5h+7SQ6lGSA9Y5xX7v7Pb1tDN9ayo CS1Q== X-Gm-Message-State: AC+VfDxxd8XFsbLmHJvEUe2+xFVKp97rXSdXYsS19PU92Hb72WvpJjXC N9YzBqkoDKJTL6CLmyhusJWs35PuT3d3xQX8i4mTXQ== X-Google-Smtp-Source: ACHHUZ4L+JHzNv6HlWmdBjRonkyWikGIyXD0OGcZhY2soKtk3FiHrs3ub07ijNaUbKOzSh/rnPq0ARlpLFg9zkYYhek= 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" Precedence: bulk List-ID: X-Mailing-List: linux-doc@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