On Tue, Aug 20, 2019 at 05:44:36PM -0700, Paul E. McKenney wrote: > On Tue, Aug 20, 2019 at 08:31:32PM -0400, Joel Fernandes wrote: > > On Tue, Aug 20, 2019 at 08:27:05PM -0400, Joel Fernandes wrote: > > [snip] > > > > > > Or is the idea to time the kfree_rcu() loop separately? (I don't see > > > > > > any such separate timing, though.) > > > > > > > > > > The kmalloc() times are included within the kfree loop. The timing of > > > > > kfree_rcu() is not separate in my patch. > > > > > > > > You lost me on this one. What happens when you just interleave the > > > > kmalloc() and kfree_rcu(), without looping, compared to the looping > > > > above? Does this get more expensive? Cheaper? More vulnerable to OOM? > > > > Something else? > > > > > > You mean pairing a single kmalloc() with a single kfree_rcu() and doing this > > > several times? The results are very similar to doing kfree_alloc_num > > > kmalloc()s, then do kfree_alloc_num kfree_rcu()s; and repeat the whole thing > > > kfree_loops times (as done by this rcuperf patch we are reviewing). > > > > > > Following are some numbers. One change is the case where we are not at all > > > batching does seem to complete even faster when we fully interleave kmalloc() > > > with kfree() while the case of batching in the same scenario completes at the > > > same time as did the "not fully interleaved" scenario. However, the grace > > > period reduction improvements and the chances of OOM'ing are pretty much the > > > same in either case. > > [snip] > > > Not fully interleaved: do kfree_alloc_num kmallocs, then do kfree_alloc_num kfree_rcu()s. And repeat this kfree_loops times. > > > ======================= > > > (1) Batching > > > rcuperf.kfree_loops=20000 rcuperf.kfree_alloc_num=8000 rcuperf.kfree_no_batch=0 rcuperf.kfree_rcu_test=1 > > > > > > root@(none):/# free -m > > > total used free shared buff/cache available > > > Mem: 977 251 686 0 39 684 > > > Swap: 0 0 0 > > > > > > [ 15.574402] Total time taken by all kfree'ers: 14185970787 ns, loops: 20000, batches: 1548 > > > > > > (2) No Batching > > > rcuperf.kfree_loops=20000 rcuperf.kfree_alloc_num=8000 rcuperf.kfree_no_batch=1 rcuperf.kfree_rcu_test=1 > > > > > > root@(none):/# free -m > > > total used free shared buff/cache available > > > Mem: 977 82 855 0 39 853 > > > Swap: 0 0 0 > > > > > > [ 13.724554] Total time taken by all kfree'ers: 12246217291 ns, loops: 20000, batches: 7262 > > > > And the diff for changing the test to do this case is as follows (I don't > > plan to fold this diff in, since I feel the existing test suffices and > > results are similar): > > But why not? It does look to be a nice simplification, after all. That's true. Ok, I'll squash it in. thanks! thanks, - Joel [snip]
