> On Dec 24, 2019, at 1:45 AM, Miles Chen <miles.chen@xxxxxxxxxxxx> wrote: > > We use kmemleak too, but a memory leakage which is caused by > alloc_pages() in a kernel device driver cannot be caught by kmemleak. > We have fought against this kind of real problems for a few years and > find a way to make the debugging easier. > > We currently have information during OOM: process Node, zone, swap, > process (pid, rss, name), slab usage, and the backtrace, order, and > gfp flags of the OOM backtrace. > We can tell many different types of OOM problems by the information > above except the alloc_pages() leakage. > > The patch does work and save a lot of debugging time. > Could we consider the "greatest memory consumer" as another useful > OOM information? This is rather situational considering there are memory leaks here and there but it is not necessary that straightforward as a single place of greatest consumer. The other question is why the offensive drivers that use alloc_pages() repeatedly without using any object allocator? Do you have examples of this in drivers that could happen?
