Re: AMD graphics performance regression in 4.15 and later

[Jean-Marc Valin]

Hi Christian,

On 04/09/2018 07:48 AM, Christian KÃnig wrote:
> Am 06.04.2018 um 17:30 schrieb Jean-Marc Valin:
>> Hi Christian,
>>
>> Is there a way to turn off these huge pages at boot-time/run-time?
> 
> Only at compile time by not setting CONFIG_TRANSPARENT_HUGEPAGE.

Any reason why
echo never > /sys/kernel/mm/transparent_hugepage/enabled
doesn't solve the problem?

Also, I assume that disabling CONFIG_TRANSPARENT_HUGEPAGE will disable
them for everything and not just what your patch added, right?

>> I'm not sure what you mean by "We mitigated the problem by avoiding the
>> slow coherent DMA code path on almost all platforms on newer kernels". I
>> tested up to 4.16 and the performance regression is just as bad as it is
>> for 4.15.
> 
> Indeed 4.16 still doesn't have that. You could use the
> amd-staging-drm-next branch or wait for 4.17.

Is there a way to pull just that change or is there too much
interactions with other changes?

> That isn't related to the GFX hardware, but to your CPU/motherboard and
> whatever else you have in the system.

Well, I have an nvidia GPU in the same system (normally only used for
CUDA) and if I use it instead of my RX 560 then I'm not seeing any
performance issue with 4.15.

> Some part of your system needs SWIOTLB and that makes allocating memory
> much slower.

What would that part be? FTR, I have a complete description of my system
at https://jmvalin.dreamwidth.org/15583.html

I don't know if it's related, but I can maybe see one thing in common
between my machine and the Core 2 Quad from the other bug report and
that's the "NUMA part". I have a dual-socket Xeon and (AFAIK) the Core 2
Quad is made of two two-core CPUs glued together with little
communication between them.

> Intel doesn't use TTM because they don't have dedicated VRAM, but the
> open source nvidia driver should be affected as well.

I'm using the proprietary nvidia driver (because CUDA). Is that supposed
to be affected as well?

> We already mitigated that problem and I don't see any solution which
> will arrive faster than 4.17.

Is that supposed to make the slowdown unnoticeable or just slightly better?

> The only quick workaround I can see is to avoid firefox, chrome for
> example is reported to work perfectly fine.

Or use an unaffected GPU/driver ;-)

Cheers,

	Jean-Marc