From: Sui Jingfeng <sui.jingfeng@linux.dev>
To: Icenowy Zheng <uwu@icenowy.me>, Xi Ruoyao <xry111@xry111.site>,
WANG Xuerui <kernel@xen0n.name>,
Huacai Chen <chenhuacai@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
"Mike Rapoport (IBM)" <rppt@kernel.org>,
Baoquan He <bhe@redhat.com>,
"Matthew Wilcox (Oracle)" <willy@infradead.org>,
David Hildenbrand <david@redhat.com>,
Zhen Lei <thunder.leizhen@huawei.com>,
Thomas Gleixner <tglx@linutronix.de>,
Zhihong Dong <donmor3000@hotmail.com>,
loongarch@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] loongarch/mm: disable WUC for pgprot_writecombine as same as ioremap_wc
Date: Wed, 18 Dec 2024 18:29:53 +0800 [thread overview]
Message-ID: <1090f735-8252-453f-b6c8-0ec35881ff32@linux.dev> (raw)
In-Reply-To: <feb3545e650c04c8cc21c40dad36dbf4076b3ebc.camel@icenowy.me>
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?
>>
--
Best regards,
Sui
next prev parent reply other threads:[~2024-12-18 10:30 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-09 4:28 [PATCH v2] loongarch/mm: disable WUC for pgprot_writecombine as same as ioremap_wc Icenowy Zheng
2023-10-09 14:32 ` Sui Jingfeng
2023-10-10 0:15 ` WANG Xuerui
2023-10-10 3:02 ` Sui Jingfeng
2023-10-10 12:26 ` Xi Ruoyao
2023-10-13 11:12 ` Sui Jingfeng
2023-10-13 12:51 ` Sui Jingfeng
2023-10-13 13:15 ` Xi Ruoyao
2023-10-13 13:53 ` Xi Ruoyao
2025-01-21 9:19 ` Sui Jingfeng
2024-12-02 16:23 ` Sui Jingfeng
2024-12-17 18:18 ` Shuah
2024-12-18 3:24 ` Sui Jingfeng
2024-12-18 6:23 ` Icenowy Zheng
2024-12-18 10:05 ` Sui Jingfeng
2024-12-18 12:37 ` Icenowy Zheng
2024-12-19 3:17 ` Sui Jingfeng
2024-12-19 4:54 ` Icenowy Zheng
2024-12-20 16:43 ` Shuah
2024-12-17 23:44 ` Icenowy Zheng
2024-12-18 3:05 ` Sui Jingfeng
2024-12-18 5:47 ` Icenowy Zheng
2024-12-18 10:29 ` Sui Jingfeng [this message]
2024-12-18 12:43 ` Icenowy Zheng
2024-12-19 2:54 ` Sui Jingfeng
2024-12-19 4:49 ` Icenowy Zheng
2024-12-19 5:49 ` Sui Jingfeng
2024-12-19 6:34 ` Icenowy Zheng
2024-12-19 7:46 ` Sui Jingfeng
2024-12-19 6:38 ` Icenowy Zheng
2024-12-19 10:39 ` Sui Jingfeng
2023-10-10 0:50 ` Icenowy Zheng
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=1090f735-8252-453f-b6c8-0ec35881ff32@linux.dev \
--to=sui.jingfeng@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=bhe@redhat.com \
--cc=chenhuacai@kernel.org \
--cc=david@redhat.com \
--cc=donmor3000@hotmail.com \
--cc=kernel@xen0n.name \
--cc=linux-kernel@vger.kernel.org \
--cc=loongarch@lists.linux.dev \
--cc=rppt@kernel.org \
--cc=tglx@linutronix.de \
--cc=thunder.leizhen@huawei.com \
--cc=uwu@icenowy.me \
--cc=willy@infradead.org \
--cc=xry111@xry111.site \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.