From: Jason Gunthorpe <jgg@nvidia.com>
To: Lu Baolu <baolu.lu@linux.intel.com>,
Joerg Roedel <joro@8bytes.org>, Kevin Tian <kevin.tian@intel.com>,
Matthew Rosato <mjrosato@linux.ibm.com>,
Robin Murphy <robin.murphy@arm.com>
Cc: linux-s390@vger.kernel.org, kvm@vger.kernel.org,
nouveau@lists.freedesktop.org, linux-rdma@vger.kernel.org,
linux-arm-msm@vger.kernel.org,
Niklas Schnelle <schnelle@linux.ibm.com>,
linux-remoteproc@vger.kernel.org, iommu@lists.linux.dev,
dri-devel@lists.freedesktop.org,
linux-stm32@st-md-mailman.stormreply.com,
Alex Williamson <alex.williamson@redhat.com>,
netdev@vger.kernel.org, ath10k@lists.infradead.org,
linux-wireless@vger.kernel.org, linux-tegra@vger.kernel.org,
Christian Borntraeger <borntraeger@linux.ibm.com>,
virtualization@lists.linux-foundation.org,
ath11k@lists.infradead.org, linux-arm-kernel@lists.infradead.org,
linux-media@vger.kernel.org
Subject: [Nouveau] [PATCH v2 00/10] Let iommufd charge IOPTE allocations to the memory cgroup
Date: Wed, 18 Jan 2023 14:00:34 -0400 [thread overview]
Message-ID: <0-v2-ce66f632bd0d+484-iommu_map_gfp_jgg@nvidia.com> (raw)
iommufd follows the same design as KVM and uses memory cgroups to limit
the amount of kernel memory a iommufd file descriptor can pin down. The
various internal data structures already use GFP_KERNEL_ACCOUNT to charge
its own memory.
However, one of the biggest consumers of kernel memory is the IOPTEs
stored under the iommu_domain and these allocations are not tracked.
This series is the first step in fixing it.
The iommu driver contract already includes a 'gfp' argument to the
map_pages op, allowing iommufd to specify GFP_KERNEL_ACCOUNT and then
having the driver allocate the IOPTE tables with that flag will capture a
significant amount of the allocations.
Update the iommu_map() API to pass in the GFP argument, and fix all call
sites. Replace iommu_map_atomic().
Audit the "enterprise" iommu drivers to make sure they do the right thing.
Intel and S390 ignore the GFP argument and always use GFP_ATOMIC. This is
problematic for iommufd anyhow, so fix it. AMD and ARM SMMUv2/3 are
already correct.
A follow up series will be needed to capture the allocations made when the
iommu_domain itself is allocated, which will complete the job.
v2:
- Prohibit bad GFP flags in the iommu wrappers
- Split out the new GFP_KERNEL usages into dedicated patches so it is
easier to check. No code change after the full series
v1: https://lore.kernel.org/r/0-v1-6e8b3997c46d+89e-iommu_map_gfp_jgg@nvidia.com
Jason Gunthorpe (10):
iommu: Add a gfp parameter to iommu_map()
iommu: Remove iommu_map_atomic()
iommu: Add a gfp parameter to iommu_map_sg()
iommu/dma: Use the gfp parameter in __iommu_dma_alloc_noncontiguous()
iommufd: Use GFP_KERNEL_ACCOUNT for iommu_map()
iommu/intel: Add a gfp parameter to alloc_pgtable_page()
iommu/intel: Support the gfp argument to the map_pages op
iommu/intel: Use GFP_KERNEL in sleepable contexts
iommu/s390: Push the gfp parameter to the kmem_cache_alloc()'s
iommu/s390: Use GFP_KERNEL in sleepable contexts
arch/arm/mm/dma-mapping.c | 11 ++--
arch/s390/include/asm/pci_dma.h | 5 +-
arch/s390/pci/pci_dma.c | 31 ++++++-----
.../drm/nouveau/nvkm/subdev/instmem/gk20a.c | 3 +-
drivers/gpu/drm/tegra/drm.c | 2 +-
drivers/gpu/host1x/cdma.c | 2 +-
drivers/infiniband/hw/usnic/usnic_uiom.c | 4 +-
drivers/iommu/dma-iommu.c | 11 ++--
drivers/iommu/intel/iommu.c | 36 +++++++------
drivers/iommu/intel/iommu.h | 2 +-
drivers/iommu/intel/pasid.c | 2 +-
drivers/iommu/iommu.c | 53 +++++++------------
drivers/iommu/iommufd/pages.c | 6 ++-
drivers/iommu/s390-iommu.c | 15 +++---
drivers/media/platform/qcom/venus/firmware.c | 2 +-
drivers/net/ipa/ipa_mem.c | 6 ++-
drivers/net/wireless/ath/ath10k/snoc.c | 2 +-
drivers/net/wireless/ath/ath11k/ahb.c | 4 +-
drivers/remoteproc/remoteproc_core.c | 5 +-
drivers/vfio/vfio_iommu_type1.c | 9 ++--
drivers/vhost/vdpa.c | 2 +-
include/linux/iommu.h | 31 +++--------
22 files changed, 119 insertions(+), 125 deletions(-)
base-commit: 5dc4c995db9eb45f6373a956eb1f69460e69e6d4
--
2.39.0
next reply other threads:[~2023-01-18 18:01 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-18 18:00 Jason Gunthorpe [this message]
2023-01-18 18:00 ` [Nouveau] [PATCH v2 01/10] iommu: Add a gfp parameter to iommu_map() Jason Gunthorpe
2023-01-19 3:45 ` Tian, Kevin
2023-01-18 18:00 ` [Nouveau] [PATCH v2 02/10] iommu: Remove iommu_map_atomic() Jason Gunthorpe
2023-01-19 3:45 ` Tian, Kevin
2023-01-18 18:00 ` [Nouveau] [PATCH v2 03/10] iommu: Add a gfp parameter to iommu_map_sg() Jason Gunthorpe
2023-01-19 3:46 ` Tian, Kevin
2023-01-18 18:00 ` [Nouveau] [PATCH v2 04/10] iommu/dma: Use the gfp parameter in __iommu_dma_alloc_noncontiguous() Jason Gunthorpe
2023-01-19 3:47 ` Tian, Kevin
2023-01-20 19:28 ` Robin Murphy
2023-01-20 20:38 ` Jason Gunthorpe
2023-01-23 13:58 ` Jason Gunthorpe
2023-01-18 18:00 ` [Nouveau] [PATCH v2 05/10] iommufd: Use GFP_KERNEL_ACCOUNT for iommu_map() Jason Gunthorpe
2023-01-19 3:48 ` Tian, Kevin
2023-01-18 18:00 ` [Nouveau] [PATCH v2 06/10] iommu/intel: Add a gfp parameter to alloc_pgtable_page() Jason Gunthorpe
2023-01-19 3:49 ` Tian, Kevin
2023-01-19 11:47 ` Baolu Lu
2023-01-18 18:00 ` [Nouveau] [PATCH v2 07/10] iommu/intel: Support the gfp argument to the map_pages op Jason Gunthorpe
2023-01-19 3:50 ` Tian, Kevin
2023-01-19 11:57 ` Baolu Lu
2023-01-19 11:59 ` Baolu Lu
2023-01-18 18:00 ` [Nouveau] [PATCH v2 08/10] iommu/intel: Use GFP_KERNEL in sleepable contexts Jason Gunthorpe
2023-01-19 3:52 ` Tian, Kevin
2023-01-19 12:00 ` Baolu Lu
2023-01-18 18:00 ` [Nouveau] [PATCH v2 09/10] iommu/s390: Push the gfp parameter to the kmem_cache_alloc()'s Jason Gunthorpe
2023-01-18 18:00 ` [Nouveau] [PATCH v2 10/10] iommu/s390: Use GFP_KERNEL in sleepable contexts Jason Gunthorpe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0-v2-ce66f632bd0d+484-iommu_map_gfp_jgg@nvidia.com \
--to=jgg@nvidia.com \
--cc=alex.williamson@redhat.com \
--cc=ath10k@lists.infradead.org \
--cc=ath11k@lists.infradead.org \
--cc=baolu.lu@linux.intel.com \
--cc=borntraeger@linux.ibm.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=iommu@lists.linux.dev \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=linux-tegra@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=mjrosato@linux.ibm.com \
--cc=netdev@vger.kernel.org \
--cc=nouveau@lists.freedesktop.org \
--cc=robin.murphy@arm.com \
--cc=schnelle@linux.ibm.com \
--cc=virtualization@lists.linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).