Re: [PATCH] libgomp, OpenMP, nvptx: Low-latency memory allocator

[Tom de Vries <tdevries@suse.de>]

On 1/5/22 15:36, Andrew Stubbs wrote:
> On 05/01/2022 13:04, Tom de Vries wrote:
>> On 1/5/22 12:08, Tom de Vries wrote:
>>> The allocators-1.c test-case doesn't compile because:
>>> ...
>>> FAIL: libgomp.c/allocators-1.c (test for excess errors)
>>> Excess errors:
>>> /home/vries/oacc/trunk/source-gcc/libgomp/testsuite/libgomp.c/allocators-1.c:7:22: 
>>> sorry, unimplemented: '    ' clause on 'requires' directive not 
>>> supported yet
>>>
>>> UNRESOLVED: libgomp.c/allocators-1.c compilation failed to produce 
>>> executable
>>> ...
>>>
>>> So, I suppose I need "[PATCH] OpenMP front-end: allow requires 
>>> dynamic_allocators" as well, I'll try again with that applied.
>>
>> After applying that, I get:
>> ...
>> WARNING: program timed out.
>> FAIL: libgomp.c/allocators-2.c execution test
>> WARNING: program timed out.
>> FAIL: libgomp.c/allocators-3.c execution test
>> ...
> 
> It works for me.....
> 
> Those tests are doing some large number of allocations repeatedly and in 
> parallel to stress the atomics. They're also slightly longer running 
> than the other tests.
>    - allocators-2 calls omp_alloc 8080 times, over 16 kernel launches, 
> some of which will fall back to PTX malloc.

I've minimized the test-case by enabling a single call in main at a 
time.  All but the last 4 take about two seconds, the last 4 hang (and 
time out at 5min).

So, this already times out for me:
...
int
main ()
{
   test (1000, omp_low_lat_mem_alloc);
   return 0;
}
...

I tried playing around with the n, and roughly there's no hang below 
100, and a hang above 200, and inbetween there may or may not be a hang.

Again the same dynamic: if there's no hang, it just takes a few seconds.

>    - allocators-3 calls omp_alloc and omp_free 8 million times each, 
> over 8 kernel launches, and takes about a minute to run on my device 
> (whether that falls back depends entirely on how the free calls 
> interleave).
> 
> Either there is a flaw in the concurrency causing some kind of deadlock, 
> or else your timeout is set too short for your device. I hope it's the 
> latter. We may need to tweak this.

At first glance, the above behaviour doesn't look like a too short timeout.

[ FTR, I'm using a GT 1030 with production branch driver version 470.86 
(which is one version behind the latest 470.94) ]

Thanks,
- Tom