> On Mon, Apr 06, 2020 at 02:56:40PM +0200, Uladzislau Rezki wrote: > > Hello, Joel. > > > > > > > > > > > > Hi Vlad, > > > > > > > > > > One concern I have is this moves the problem a bit further down. My belief is > > > > > we should avoid the likelihood of even needing an rcu_head allocated for the > > > > > headless case, to begin with - than trying to do damage-control when it does > > > > > happen. The only way we would end up needing an rcu_head is if we could not > > > > > allocate an array. > > > > > > > > > Let me share my view on all such caching. I think that now it becomes less as > > > > the issue, because of we have now https://lkml.org/lkml/2020/4/2/383 patch. > > > > I see that it does help a lot. I tried to simulate low memory condition and > > > > apply high memory pressure with that. I did not manage to trigger the > > > > "synchronize rcu" path at all. It is because of using much more permissive > > > > parameters when we request a memory from the SLAB(direct reclaim, etc...). > > > > > > That's a good sign that we don't hit this path in your tests. > > > > > Just one request, of course if you have a time :) Could you please > > double check on your test environment to stress the system to check > > if you also can not hit it? > > > > How i test it. Please apply below patch: > > This is of course a double challenge. > > I can assure you that even if we cannot make it happen in the comfort and > safety of our tests systems, someone somewhere will make it happen all > the time. Because there is a very large number of Linux systems running > out there. > > Which leads to the other challenge: How do we test this code path? > I have added extra tests to my "vmalloc tests" https://lkml.org/lkml/2020/4/2/384 for stressing head/headless variants. Also we have rcuperf module. Running them together under KVM(selftests) would be good. Plus we can add a counter of the path we think is bad, synchronize_rcu() and so on. Thanks! -- Vlad Rezki
