[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.21.2109141838290.21985@sstabellini-ThinkPad-T480s>
Date: Tue, 14 Sep 2021 18:51:01 -0700 (PDT)
From: Stefano Stabellini <sstabellini@...nel.org>
To: rm.skakun@...il.com
cc: Jan Beulich <jbeulich@...e.com>,
Roman Skakun <rm.skakun@...il.com>,
Andrii Anisov <andrii_anisov@...m.com>,
Roman Skakun <roman_skakun@...m.com>,
Jonathan Corbet <corbet@....net>,
Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
Michael Ellerman <mpe@...erman.id.au>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Paul Mackerras <paulus@...ba.org>,
Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
Boris Ostrovsky <boris.ostrovsky@...cle.com>,
Juergen Gross <jgross@...e.com>,
Stefano Stabellini <sstabellini@...nel.org>,
Marek Szyprowski <m.szyprowski@...sung.com>,
Robin Murphy <robin.murphy@....com>,
"Paul E. McKenney" <paulmck@...nel.org>,
Randy Dunlap <rdunlap@...radead.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Thomas Gleixner <tglx@...utronix.de>,
"Maciej W. Rozycki" <macro@...am.me.uk>,
Muchun Song <songmuchun@...edance.com>,
Viresh Kumar <viresh.kumar@...aro.org>,
Peter Zijlstra <peterz@...radead.org>,
Lu Baolu <baolu.lu@...ux.intel.com>,
Mike Rapoport <rppt@...nel.org>, Will Deacon <will@...nel.org>,
xen-devel@...ts.xenproject.org, linux-mips@...r.kernel.org,
linuxppc-dev@...ts.ozlabs.org, linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org, iommu@...ts.linux-foundation.org,
hch@....de
Subject: Re: [PATCH] swiotlb: set IO TLB segment size via cmdline
On Tue, 14 Sep 2021, Christoph Hellwig wrote:
> On Tue, Sep 14, 2021 at 05:29:07PM +0200, Jan Beulich wrote:
> > I'm not convinced the swiotlb use describe there falls under "intended
> > use" - mapping a 1280x720 framebuffer in a single chunk? (As an aside,
> > the bottom of this page is also confusing, as following "Then we can
> > confirm the modified swiotlb size in the boot log:" there is a log
> > fragment showing the same original size of 64Mb.
>
> It doesn't. We also do not add hacks to the kernel for whacky out
> of tree modules.
Also, Option 1 listed in the webpage seems to be a lot better. Any
reason you can't do that? Because that option both solves the problem
and increases performance.
Powered by blists - more mailing lists