Messages in this thread |  | | | Date | Fri, 12 Feb 2010 11:38:12 +0900 | | Subject | Re: tracking memory usage/leak in "inactive" field in /proc/meminfo? | | From | Minchan Kim <> |
| |
On Fri, Feb 12, 2010 at 3:54 AM, Chris Friesen <cfriesen@nortel.com> 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 from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |