[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <932a9a93c00082645df465862231f6d8c91f3bf6.camel@icenowy.me>
Date: Wed, 18 Dec 2024 20:43:54 +0800
From: Icenowy Zheng <uwu@...nowy.me>
To: Sui Jingfeng <sui.jingfeng@...ux.dev>, Xi Ruoyao <xry111@...111.site>,
WANG Xuerui <kernel@...0n.name>, Huacai Chen <chenhuacai@...nel.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>, "Mike Rapoport (IBM)"
<rppt@...nel.org>, Baoquan He <bhe@...hat.com>, "Matthew Wilcox (Oracle)"
<willy@...radead.org>, David Hildenbrand <david@...hat.com>, Zhen Lei
<thunder.leizhen@...wei.com>, Thomas Gleixner <tglx@...utronix.de>, Zhihong
Dong <donmor3000@...mail.com>, loongarch@...ts.linux.dev,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] loongarch/mm: disable WUC for pgprot_writecombine as
same as ioremap_wc
在 2024-12-18星期三的 18:29 +0800,Sui Jingfeng写道:
>
> On 2024/12/18 13:47, Icenowy Zheng wrote:
> > 在 2024-12-18星期三的 11:05 +0800,Sui Jingfeng写道:
> > > Hi,
> > >
> > >
> > > On 2024/12/18 07:44, Icenowy Zheng wrote:
> > > > 在 2024-12-03星期二的 00:23 +0800,Sui Jingfeng写道:
> > > > > Hi,
> > > > >
> > > > > On 10/10/23 20:26, Xi Ruoyao wrote:
> > > > > > On Tue, 2023-10-10 at 11:02 +0800, Sui Jingfeng wrote:
> > > > > >
> > > > > > > On LoongArch, cached mapping and uncached mappings are
> > > > > > > DMA-
> > > > > > > coherent and guaranteed by
> > > > > > > the hardware. While WC mappings is *NOT* DMA-coherent
> > > > > > > when 3D
> > > > > > > GPU
> > > > > > > is involved. Therefore,
> > > > > > > On downstream kernel, We disable write combine(WC)
> > > > > > > mappings
> > > > > > > at
> > > > > > > the drm drivers side.
> > > > > > Why it's only an issue when 3D GPU is involved?
> > > > > No one saying that only 3D GPU is suffer from this kind of
> > > > > issue,
> > > > > I just meant that the issue is there at least for GPU
> > > > >
> > > > > > What's the difference between 3D GPUs and other devices?
> > > > > > Is it
> > > > > > possible that the other
> > > > > > devices (say neural accelerators) start to perform DMA
> > > > > > accesses
> > > > > > in
> > > > > > a
> > > > > > similar way and then suddenly broken?
> > > > > You, the patch contributor or the maintainer or whatever
> > > > > stuff
> > > > > should carry on the test, right?
> > > > Well doing some test on PCIe peripherals need some professional
> > > > tool,
> > > > then I assume who raises the idea should do it, because not
> > > > everyone
> > > > can do.
> > >
> > > You are posting the patch, and then you are acclaiming that you
> > > are
> > > not even able to do sufficient test? right?
> > What I can test is that w/o this patch things break and w/ this
> > patch
> > things work.
>
>
> > If you are against this patch, you need to provide more effective
> > evidence / a better solution than my approach.
>
>
> I have told you several times, we are asking for hardware details.
> Why the Loongarch suffer from the WC bug, like the Loongson Mips?
> Why the performance of drm/ast's drop dramatically when your patch
> is applied?
Well the fact is that before applying this patch, graphical glitches
usually happen on amdgpu/radeon, and after applying this they
disappears -- this matches what happens when WC is enabled on MIPS
Loongson.
For the fact of drm/ast's dramatical drop, it's because write to the
framebuffer can no longer be reordered. In fact if using amdgpu/radeon
w/o graphical acceleration, the same issue happens. (This can be
clearly seen when on MIPS Loongson w/ RS780E -- outputing the boot log
can dramatically slow down the boot process).
What I can assume now is that the Loongson WC/WUC is safe for display
framebuffers, but not safe for GPU commands/textures/etc.
>
>
> > >
Powered by blists - more mailing lists