Messages in this thread Patch in this message | | | Date | Tue, 1 Dec 1998 18:12:05 +0100 (CET) | From | Andrea Arcangeli <> | Subject | Re: 2.1.130 mem usage. |
| |
I read now the latest mm changes from you, Stephen. So now we have only 1 bit to do page aging and we have an unused field in the mem_map_t. Logically 32 bit can give us more info than one bit. Instead of waste 32 bit and use 1 bit, why we don' t drop the bit and use the 32 bit instead? I can agree that having both PG_referenced in ->flags and ->age it' s not a simple and clean approch. I can agree to use only 1 bit but sure I don' t want the wasting the `unused' field in the mem_map_t ;).
On Mon, 30 Nov 1998, Stephen C. Tweedie wrote:
>@@ -214,7 +214,15 @@ > if (shrink_one_page(page, gfp_mask)) > return 1; > count_max--; >- if (page->inode || page->buffers) >+ /* >+ * If the page we looked at was recyclable but we didn't >+ * reclaim it (presumably due to PG_referenced), don't >+ * count it as scanned. This way, the more referenced >+ * page cache pages we encounter, the more rapidly we >+ * will age them. >+ */ >+ if (atomic_read(&page->count) != 1 || >+ (!page->inode && !page->buffers)) > count_min--;
I don' t think count_min should count the number of tries on pages we have no chance to free. It should be the opposite according to me.
I think that we should decrease count_min if:
((page->inode || page->buffers) && atomic_read(->count) == 1)
is true instead. I am going to do this in my kernel now.
2.1.129 does also this (that will cause shrink_mmap() to be more light):
@@ -212,8 +207,8 @@ struct page * page; int count_max, count_min; - count_max = (limit<<2) >> (priority>>1); - count_min = (limit<<2) >> (priority); + count_max = (limit<<1) >> (priority>>1); + count_min = (limit<<1) >> (priority); page = mem_map + clock; do { 2.1.130 does also this:
@@ -188,7 +180,7 @@ * asynchronously. That's no problem, shrink_mmap() can * correctly clean up the occassional unshared page * which gets left behind in the swap cache. */ - free_page_and_swap_cache(page); + free_page(page); return 1; /* we slept: the process may not exist any more */ } Doing this we are not swapping out really I think, because the page now is also on the hd, but it' s still in memory and so shrink_mmap() will have the double of the work to do.
@@ -218,7 +210,7 @@ flush_cache_page(vma, address); pte_clear(page_table); flush_tlb_page(vma, address); - entry = page_unuse(page_map); + entry = (atomic_read(&page_map->count) == 1); __free_page(page_map); return entry; } This will cause the double of work to shrink_mmap() too I think.
I' ll try to reverse these patches right now in my own tree.
Andrea Arcangeli
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |