On Fri, Feb 12, 2010 at 3:54 AM, Chris Friesen <cfriesen@xxxxxxxxxx> wrote: > That just makes the comparison even worse...it means that there is more > memory in active/inactive that isn't accounted for in any other category > in /proc/meminfo. Hmm. It's very strange. It's impossible if your kernel and drivers is normal. Could you grep sources who increases NR_ACTIVE/INACTIVE? I doubt one of your driver does increase and miss decrease. >> Now kernel don't account kernel memory allocations except SLAB. > > I don't think that's entirely accurate. I think cached, buffers, > pagetables, vmallocUsed are all kernel allocations. Granted, they're > generally on behalf of userspace. Yes. I just said simple. What I means kernel doesn't account whole memory usage. :) > I have a modified version of that which I picked up as part of the > kmemleak backport. However, it doesn't help unless I can narrow down > *which* pages I should care about. kmemleak doesn't support page allocator and ioremap. Above URL patch just can tell who requests page which is using(ie, not free) now. > I tried using kmemleak directly, but it didn't find anything. I've also > tried checking for inactive pages which haven't been written to in 10 > minutes, and haven't had much luck there either. But active/inactive > keeps growing, and I don't know why. If leak cause by alloc_page or __get_free_pages, kmemleak can't find leak. > > Chris > -- Kind regards, Minchan Kim -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href