Messages in this thread | | | Date | Tue, 26 Aug 2003 18:03:14 +0100 (BST) | From | Hugh Dickins <> | Subject | Re: Strange memory usage reporting |
| |
On Tue, 26 Aug 2003, Jaroslav Kysela wrote: > > Yes, it seems so. The do_no_page() function in mm/memory.c does accounting > for reserved pages (++mm->rss), but in zap_pte_range() there is a check > preventing increase the count of freed pages. > > Here is a patch for VM gurus to review (for 2.4 kernel, but it should > apply to 2.6 as well): > > ===== mm/memory.c 1.57 vs edited ===== > --- 1.57/mm/memory.c Fri Jun 13 18:26:23 2003 > +++ edited/mm/memory.c Tue Aug 26 15:33:28 2003 > @@ -1306,7 +1306,8 @@ > */ > /* Only go through if we didn't race with anybody else... */ > if (pte_none(*page_table)) { > - ++mm->rss; > + if (!PageReserved(new_page)) > + ++mm->rss; > flush_page_to_ram(new_page); > flush_icache_page(vma, new_page); > entry = mk_pte(new_page, vma->vm_page_prot);
You're right (but please rediff against 2.4.22 when you send Marcelo).
You may wonder how this has taken so long to show up: because usually drivers which mmap Reserved pages use remap_page_range on them, and so never fault to do_no_page.
Which is the driver involved? Though it's not wrong to give do_no_page a Reserved page, beware of the the page->count accounting: while it's Reserved, get_page or page_cache_get raises the count, but put_page or page_cache_release does not decrement it - very easy to end up with the page never freed.
Hugh
- 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/
| |