> While checking out some memory problems I noticed a discrepancy between
> the number of free pages (on the free lists) and the number of unused
> pages (page->count == 0), as reported by shift-scroll-lock. The number
> of unused pages is always higher, typically by 80, sometimes by several
> hundred.
> As I'm not aware of any mechanism by which a page's count can go to 0
> without freeing it, I suspect that this may indicate memory leaks caused
> by doing an atomic_dec(&page->count) instead of __free_page(page). So
> my question is: are there legitimate mechanisms for dropping the page
> count to 0, or can I assume that there's a memory leak to be tracked
> down?
There's no memory leak to track down, or at least there shouldn't be ;)
What you're seeing is a side effect of our dirty little memory allocator
known as the buddy system w/several ways of marking a page as 'free'.
Pages that are allocated but have a use count of zero are of order >0 -
only the first page of such chunks actually have a use count of 1
(anything else would just be evil). Hope that clears it up for you!
-ben