From: Matthew Wilcox <willy@infradead.org>
To: David Rientjes <rientjes@google.com>
Cc: Pasha Tatashin <pasha.tatashin@soleen.com>,
Andrew Morton <akpm@linux-foundation.org>,
alim.akhtar@samsung.com, alyssa@rosenzweig.io,
asahi@lists.linux.dev, baolu.lu@linux.intel.com,
bhelgaas@google.com, cgroups@vger.kernel.org, corbet@lwn.net,
david@redhat.com, dwmw2@infradead.org, hannes@cmpxchg.org,
heiko@sntech.de, iommu@lists.linux.dev, jernej.skrabec@gmail.com,
jonathanh@nvidia.com, joro@8bytes.org,
krzysztof.kozlowski@linaro.org, linux-doc@vger.kernel.org,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, linux-rockchip@lists.infradead.org,
linux-samsung-soc@vger.kernel.org, linux-sunxi@lists.linux.dev,
linux-tegra@vger.kernel.org, lizefan.x@bytedance.com,
marcan@marcan.st, mhiramat@kernel.org, m.szyprowski@samsung.com,
paulmck@kernel.org, rdunlap@infradead.org, robin.murphy@arm.com,
samuel@sholland.org, suravee.suthikulpanit@amd.com,
sven@svenpeter.dev, thierry.reding@gmail.com, tj@kernel.org,
tomas.mudrunka@gmail.com, vdumpa@nvidia.com, wens@csie.org,
will@kernel.org, yu-cheng.yu@intel.com
Subject: Re: [PATCH v2 01/10] iommu/vt-d: add wrapper functions for page allocations
Date: Sun, 24 Dec 2023 21:48:00 +0000 [thread overview]
Message-ID: <ZYinEGCdl8mZjmXi@casper.infradead.org> (raw)
In-Reply-To: <1fd66377-030c-2e48-e658-4669bbf037e9@google.com>
On Sun, Dec 24, 2023 at 01:30:50PM -0800, David Rientjes wrote:
> > > s/pages/page/ here and later in this file.
> >
> > In this file, where there a page with an "order", I reference it with
> > "pages", when no order (i.e. order = 0), I reference it with "page"
> >
> > I.e.: __iommu_alloc_page vs. __iommu_alloc_pages
> >
>
> Eh, the struct page points to a (potentially compound) page, not a set or
> list of pages. I won't bikeshed on it, but "struct page *pages" never
> makes sense unless it's **pages or *pages[] :)
I'd suggest that 'pages' also makes sense when _not_ using __GFP_COMP,
as we do in fact allocate an array of pages in that case.
That said, we shouldn't encourage the use of non-compound allocations.
It would also be good for someone to define a memdesc for iommu memory
like we have already for slab. We'll need it eventually, and it'll work
out better if someone who understands iommus (ie not me) does it.
next prev parent reply other threads:[~2023-12-24 21:48 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-30 20:14 [PATCH v2 00/10] IOMMU memory observability Pasha Tatashin
2023-11-30 20:14 ` [PATCH v2 01/10] iommu/vt-d: add wrapper functions for page allocations Pasha Tatashin
2023-12-14 17:58 ` David Rientjes
2023-12-14 19:16 ` Pasha Tatashin
2023-12-24 21:30 ` David Rientjes
2023-12-24 21:48 ` Matthew Wilcox [this message]
2023-12-26 17:57 ` Pasha Tatashin
2023-12-26 6:09 ` Liu, Jingqi
2023-12-26 17:14 ` Pasha Tatashin
2023-11-30 20:14 ` [PATCH v2 02/10] iommu/amd: use page allocation function provided by iommu-pages.h Pasha Tatashin
2023-12-24 21:34 ` David Rientjes
2023-11-30 20:14 ` [PATCH v2 03/10] iommu/io-pgtable-arm: " Pasha Tatashin
2023-12-24 21:34 ` David Rientjes
2023-11-30 20:14 ` [PATCH v2 04/10] iommu/io-pgtable-dart: " Pasha Tatashin
2023-12-24 21:36 ` David Rientjes
2023-12-26 18:08 ` Pasha Tatashin
2023-11-30 20:14 ` [PATCH v2 05/10] iommu/exynos: " Pasha Tatashin
2023-12-24 21:37 ` David Rientjes
2023-11-30 20:15 ` [PATCH v2 06/10] iommu/rockchip: " Pasha Tatashin
2023-12-24 21:39 ` David Rientjes
2023-11-30 20:15 ` [PATCH v2 07/10] iommu/sun50i: " Pasha Tatashin
2023-12-24 21:39 ` David Rientjes
2023-11-30 20:15 ` [PATCH v2 08/10] iommu/tegra-smmu: " Pasha Tatashin
2023-12-24 21:40 ` David Rientjes
2023-11-30 20:15 ` [PATCH v2 09/10] iommu: observability of the IOMMU allocations Pasha Tatashin
2023-12-14 17:59 ` David Rientjes
2023-12-14 19:18 ` Pasha Tatashin
2023-11-30 20:15 ` [PATCH v2 10/10] iommu: account IOMMU allocated memory Pasha Tatashin
2023-12-14 18:02 ` David Rientjes
2023-12-15 21:11 ` Pasha Tatashin
2023-12-24 21:44 ` David Rientjes
2023-12-24 21:49 ` [PATCH v2 00/10] IOMMU memory observability David Rientjes
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=ZYinEGCdl8mZjmXi@casper.infradead.org \
--to=willy@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=alim.akhtar@samsung.com \
--cc=alyssa@rosenzweig.io \
--cc=asahi@lists.linux.dev \
--cc=baolu.lu@linux.intel.com \
--cc=bhelgaas@google.com \
--cc=cgroups@vger.kernel.org \
--cc=corbet@lwn.net \
--cc=david@redhat.com \
--cc=dwmw2@infradead.org \
--cc=hannes@cmpxchg.org \
--cc=heiko@sntech.de \
--cc=iommu@lists.linux.dev \
--cc=jernej.skrabec@gmail.com \
--cc=jonathanh@nvidia.com \
--cc=joro@8bytes.org \
--cc=krzysztof.kozlowski@linaro.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=linux-sunxi@lists.linux.dev \
--cc=linux-tegra@vger.kernel.org \
--cc=lizefan.x@bytedance.com \
--cc=m.szyprowski@samsung.com \
--cc=marcan@marcan.st \
--cc=mhiramat@kernel.org \
--cc=pasha.tatashin@soleen.com \
--cc=paulmck@kernel.org \
--cc=rdunlap@infradead.org \
--cc=rientjes@google.com \
--cc=robin.murphy@arm.com \
--cc=samuel@sholland.org \
--cc=suravee.suthikulpanit@amd.com \
--cc=sven@svenpeter.dev \
--cc=thierry.reding@gmail.com \
--cc=tj@kernel.org \
--cc=tomas.mudrunka@gmail.com \
--cc=vdumpa@nvidia.com \
--cc=wens@csie.org \
--cc=will@kernel.org \
--cc=yu-cheng.yu@intel.com \
/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).