Messages in this thread | | | Date | Wed, 22 Jul 1998 18:59:26 -0400 | From | Bill Hawes <> | Subject | Re: 2.1.110 freepages.min change |
| |
Linus Torvalds wrote:
> Essentially the new logic is that if we didn't find anything else that > can easily be free'd, we just prune the _whole_ dcache. That either > happens very seldom indeed (on my machine ;), or if it happens often it > just means that the machine is low on memory in which case it is > entirely reasonable to throw away the dcache aggressively.
That's not been my experience here. I added a printk to monitor the shrink call, and I see repeated calls at priority 6 draining the dcache while doing a kernel compile. This is on a 32M machine under no particular memory stress -- it can easily handle two simultaneous compiles with only light swapping.
The try_to_free_page logic does make transitions between states even when memory is not in short supply, whether because the page cache has been referenced recently or the mapped pages made young. So when it leaves the "swap_out" state, there's likely memory available in "shrink_mmap", but the dcache still gets trashed.
At the very least waiting for priority 4 or 3 would allow all of the states to be checked for memory.
Regards, Bill
- 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.altern.org/andrebalsa/doc/lkml-faq.html
| |