Messages in this thread | ![/](/images/icornerl.gif) | | Date | Thu, 20 Aug 2020 22:29:57 -0400 | From | Qian Cai <> | Subject | Re: [PATCH] mm/kmemleak: rely on rcu for task stack scanning |
| |
On Thu, Aug 20, 2020 at 06:27:50PM -0700, Davidlohr Bueso wrote: > On Thu, 20 Aug 2020, Qian Cai wrote: > > > On Thu, Aug 20, 2020 at 01:39:02PM -0700, Davidlohr Bueso wrote: > > > kmemleak_scan() currently relies on the big tasklist_lock > > > hammer to stabilize iterating through the tasklist. Instead, > > > this patch proposes simply using rcu along with the rcu-safe > > > for_each_process_thread flavor (without changing scan semantics), > > > which doesn't make use of next_thread/p->thread_group and thus > > > cannot race with exit. Furthermore, any races with fork() > > > and not seeing the new child should be benign as it's not > > > running yet and can also be detected by the next scan. > > > > It is not entirely clear to me what problem the patch is trying to solve. If > > this is about performance, we will probably need some number. > > So in this case avoiding the tasklist_lock could prove beneficial for performance > considering the scan operation is done periodically. I have seen improvements > of 30%-ish when doing similar replacements on very pathological microbenchmarks > (ie stressing get/setpriority(2)). > > However my main motivation is that it's one less user of the global lock, > something that Linus has long time wanted to see gone eventually (if ever) > even if the traditional fairness issues has been dealt with now with qrwlocks. > Of course this is a very long ways ahead. This patch also kills another user > of the deprecated tsk->thread_group.
This makes thing clearer.
Reviewed-by: Qian Cai <cai@lca.pw>
| ![\](/images/icornerr.gif) |