Re: [PATCH 05/16] iommu/io-pgtable-arm-v7s: use page allocation function provided by iommu-pages.h

From: Pasha Tatashin <pasha.tatashin@soleen.com>
To: Robin Murphy <robin.murphy@arm.com>
Cc: akpm@linux-foundation.org, alex.williamson@redhat.com,
	 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, jasowang@redhat.com,
	 jernej.skrabec@gmail.com, jgg@ziepe.ca, jonathanh@nvidia.com,
	joro@8bytes.org,  kevin.tian@intel.com,
	krzysztof.kozlowski@linaro.org, kvm@vger.kernel.org,
	 linux-arm-kernel@lists.infradead.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, mst@redhat.com,
	m.szyprowski@samsung.com,  netdev@vger.kernel.org,
	paulmck@kernel.org, rdunlap@infradead.org,  samuel@sholland.org,
	suravee.suthikulpanit@amd.com, sven@svenpeter.dev,
	 thierry.reding@gmail.com, tj@kernel.org,
	tomas.mudrunka@gmail.com,  vdumpa@nvidia.com,
	virtualization@lists.linux.dev, wens@csie.org,  will@kernel.org,
	yu-cheng.yu@intel.com
Subject: Re: [PATCH 05/16] iommu/io-pgtable-arm-v7s: use page allocation function provided by iommu-pages.h
Date: Tue, 28 Nov 2023 18:32:20 -0500	[thread overview]
Message-ID: <CA+CK2bDKaXqemr2Hp=MRxxMB_=AoRnUK_D2SGm9cDkKa+JaT7A@mail.gmail.com> (raw)
In-Reply-To: <6f9ff0aa-7713-4de1-869e-4725828942e4@arm.com>

On Tue, Nov 28, 2023 at 6:08 PM Robin Murphy <robin.murphy@arm.com> wrote:
>
> On 2023-11-28 10:55 pm, Pasha Tatashin wrote:
> >>>                kmem_cache_free(data->l2_tables, table);
> >
> > We only account page allocations, not subpages, however, this is
> > something I was surprised about this particular architecture of why do
> > we allocate l2 using kmem ? Are the second level tables on arm v7s
> > really sub-page in size?
>
> Yes, L2 tables are 1KB, so the kmem_cache could still quite easily end
> up consuming significantly more memory than the L1 table, which is
> usually 16KB (but could potentially be smaller depending on the config,
> or up to 64KB with the Mediatek hacks).

I am OK removing support for this architecture, or keeping only info
for L1, I do not think there is a reason to worry about sub-page
accounting only for v7s.

Pasha

>
> Thanks,
> Robin.