> > Benjamin C R LaHaise wrote:
> > > 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!
> >
> > Thanks, much clearer now. But my next question would be how to
> > distinguish such order > 0 pages from memory-leaked pages. I'd like to
> > modify the show_mem function so that its "free pages" count exactly
> > agrees with the freelist, in the absence of leaks.
> >
> > When an order > 0 page is released, does the memory allocator sweep up
> > all trailing adjacent pages with count = 0 and assume they were part of
> > the initial allocation?
>
> No, it uses the buddy system bitmaps, and depends on the fact that you
> always release the same order as you allocated.
>
> So to really see what's free or not, you have to look at the bitmaps in
> addition to the page counts.. Maybe somebody can come up with a good way
> of doing all this, I certainly can't think of anything offhand,
What I did in my kswapd changes (haven't had time to work on it
lately...) was to add an order field to struct page - this was enough for
when I walked the page_map table looking for free pages, and there isn't
a need to lookup these values for an arbitrary page right now.
Personally I'd like to apply some slab-like scheme to page allocations -
mostly to separate kernel vs user pages. This way we'd get much better
bahaviour wrt fragmentation. Maybe all memory could be divided into 128k
blocks that are marked for a specific purpose. I hope play with this idea
when I've some time...
-ben