Hi Sebastian, On 11/18/2024 11:39 PM, Sebastian Andrzej Siewior wrote: > On 2024-11-18 09:07:58 [+0800], Hou Tao wrote: >> From: Hou Tao <houtao1@xxxxxxxxxx> >> >> Hi, > Hi, > >> Please see individual patches for more details. Comments are always >> welcome. > This might be a coincidence but it seems I get > > | helper_fill_hashmap(282):FAIL:can't update hashmap err: Unknown error -12 > | test_maps: test_maps.c:1379: __run_parallel: Assertion `status == 0' failed. > > more often with the series when I do ./test_maps. I never managed to > pass the test with series while it passed on v6.12. I'm not blaming the > series, just pointing this out it might be known… Thanks for the information. 12 is ENOMEM, so the hash map failed to allocate an element for it. There are multiple possible reasons for ENOMEM: 1) something is wrong for bpf mem allocator. E.g., it could not refill the free list timely. It may be possible when running under RT, because the irq work is threaded under RT. 2) the series causes the shortage of memory (e.g., It uses a lot memory then free these memory, but the reclaim of the memory is slow) Could you please share the kernel config file and the VM setup, so I could try to reproduce the problem ? > > In 08/10 you switch the locks to raw_spinlock_t. I was a little worried > that a lot of elements will make the while() loop go for a long time. Is > there a test for this? I run into "test_progs -a map_kptr" and noticed > something else… The concern is the possibility of hard-lockup, right ? The total time used for update or deletion is decided by the max_prefixlen. The typical use case will use 32 or 128 as the max_prefixlen. The max value of max_prefixlen is LPM_DATA_SIZE_MAX * 8 = 2048, I think the loop time will be fine. Will try to construct some test cases for it. > > Sebastian
