On 11/8/2024 3:51 PM, Liu, Monk wrote:
> [AMD Official Use Only - AMD Internal Distribution Only]
>
> Christian/Lijo
>
> We verified all approaches, and we know what works and not works, obviously the mb() doesn't work.
>
> The way of mb() between set wptr_polling and kicking off doorbell is theoretically correct, and I'm not object to do so... but this won't resolve the issue we hit.
> First of all, USWC will have some chance that the data is still in CPU's WC storage place and not flushed to the memory and even with MB() get rid of re-ordering
This is the wrong premise.
For x86, I see this -
#define mb() asm volatile("mfence" : : : "memory")
Below is Intel Arch Manual which clearly mentions any prior buffered
writes are *drained to memory* with mfence (AMD arch manual has a much
clearer definition about WC itself).
Program synchronization can also be carried out with serializing
instructions (see Section 10.3). These instructions
are typically used at critical procedure or task boundaries to force
completion of all previous instructions before a
jump to a new section of code or a context switch occurs. " Like the I/O
instructions, the processor waits until all
previous instructions have been completed and all buffered writes have
been drained to memory before executing
the serializing instruction"
MFENCE — Serializes all store and load operations that occurred prior to
the MFENCE instruction in the
program instruction stream.
Just because it worked because of memory type change doesn't imply that
it is the right way to solve this. You could be looking at a system
config bug.
Thanks,
Lijo
> GPU might still have a chance to read stalled data from ring buffer as long as it is mapped USWC.
>
> This is why only cache plus snoop memory can get rid of inconsistence issues.
>
> Besides, do you know what's the rational to keep all GFX KCQ cache+snoop but only HIQ/KIQ from KFD configured to USWC ?
>
> For performance concern that looks to me always the second priority compared to "correct" especially under the case HIQ contributes very little to ROCM performance when switching to cache mapping.
>
>
> Monk Liu | Cloud GPU & Virtualization | AMD
>
>
>
>
>
>
>
> -----Original Message-----
> From: Koenig, Christian <Christian.Koenig@xxxxxxx>
> Sent: Thursday, November 7, 2024 7:57 PM
> To: Lazar, Lijo <Lijo.Lazar@xxxxxxx>; Alex Deucher <alexdeucher@xxxxxxxxx>; Zhao, Victor <Victor.Zhao@xxxxxxx>
> Cc: amd-gfx@xxxxxxxxxxxxxxxxxxxxx; Liu, Monk <Monk.Liu@xxxxxxx>; Yang, Philip <Philip.Yang@xxxxxxx>; Kuehling, Felix <Felix.Kuehling@xxxxxxx>
> Subject: Re: [PATCH 2/2] drm/amdkfd: use cache GTT buffer for PQ and wb pool
>
> Am 07.11.24 um 06:58 schrieb Lazar, Lijo:
>> On 11/6/2024 8:42 PM, Alex Deucher wrote:
>>> On Wed, Nov 6, 2024 at 1:49 AM Victor Zhao <Victor.Zhao@xxxxxxx> wrote:
>>>> From: Monk Liu <Monk.Liu@xxxxxxx>
>>>>
>>>> As cache GTT buffer is snooped, this way the coherence between CPU
>>>> write and GPU fetch is guaranteed, but original code uses WC +
>>>> unsnooped for HIQ PQ(ring buffer) which introduces coherency issues:
>>>> MEC fetches a stall data from PQ and leads to MEC hang.
>>> Can you elaborate on this? I can see CPU reads being slower because
>>> the memory is uncached, but the ring buffer is mostly writes anyway.
>>> IIRC, the driver uses USWC for most if not all of the other ring
>>> buffers managed by the kernel. Why aren't those a problem?
>> We have this on other rings -
>> mb();
>> amdgpu_ring_set_wptr(ring);
>>
>> I think the solution should be to use barrier before write pointer
>> updates rather than relying on PCIe snooping.
>
> Yeah, completely agree as well. The barrier also takes care of preventing the compiler from re-ordering writes.
>
> Regards,
> Christian.
>
>>
>> Thanks,
>> Lijo
>>
>>> Alex
>>>
>>>> Signed-off-by: Monk Liu <Monk.Liu@xxxxxxx>
>>>> ---
>>>> drivers/gpu/drm/amd/amdkfd/kfd_device.c | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
>>>> b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
>>>> index 1f1d79ac5e6c..fb087a0ff5bc 100644
>>>> --- a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
>>>> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
>>>> @@ -779,7 +779,7 @@ bool kgd2kfd_device_init(struct kfd_dev *kfd,
>>>> if (amdgpu_amdkfd_alloc_gtt_mem(
>>>> kfd->adev, size, &kfd->gtt_mem,
>>>> &kfd->gtt_start_gpu_addr, &kfd->gtt_start_cpu_ptr,
>>>> - false, true)) {
>>>> + false, false)) {
>>>> dev_err(kfd_device, "Could not allocate %d bytes\n", size);
>>>> goto alloc_gtt_mem_failure;
>>>> }
>>>> --
>>>> 2.34.1
>>>>
>
