On Tue, 30 Jul 2019 16:22:37 -0400 Qian Cai <cai@xxxxxx> wrote: > On Tue, 2019-07-30 at 12:57 -0700, Andrew Morton wrote: > > On Sat, 27 Jul 2019 14:23:33 +0100 Catalin Marinas <catalin.marinas@xxxxxxx> > > wrote: > > > > > Add mempool allocations for struct kmemleak_object and > > > kmemleak_scan_area as slightly more resilient than kmem_cache_alloc() > > > under memory pressure. Additionally, mask out all the gfp flags passed > > > to kmemleak other than GFP_KERNEL|GFP_ATOMIC. > > > > > > A boot-time tuning parameter (kmemleak.mempool) is added to allow a > > > different minimum pool size (defaulting to NR_CPUS * 4). > > > > Why would anyone ever want to alter this? Is there some particular > > misbehaviour which this will improve? If so, what is it? > > So it can tolerant different systems and workloads. For example, there are some > machines with slow disk and fast CPUs. When they are under memory pressure, it > could take a long time to swap before the OOM kicks in to free up some memory. > As the results, it needs a large mempool for kmemleak or suffering from higher > chance of a kmemleak metadata allocation failure. This sort of thing should be in the changelog and in the user-facing documentation please. Also, we should document the user-visible effects of this failure so that users can determine whether this tunable will help them.
