lkml.org 
[lkml]   [2003]   [Aug]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:48    [W:0.752 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site