Err? get_free_page / try_to_free_pages

Steve Dodd (dirk@loth.demon.co.uk)
Wed, 10 Feb 1999 16:40:03 +0000


Hi,

I'm probably about to embarrass myself here by demonstrating how poor my
understanding of the kernel sources is, but no doubt the responses will be
educational..

If get_free_pages is called when we are in a low memory situation,
it calls try_to_free_pages, and if that returns false, it falls out without
even trying unless the allocation is __GFP_HIGH or __GFP_MED.

However, try_to_free_pages does some things - calling kmem_cache_reap and
shrink_dcache_memory - which presumably free memory, but without checking
if they have; so even if they freed up billions of pages, try_to_free_pages
returns 0 and get_free_pages fails. I think it also should call
free_inode_memory(), because even though the icache doesn't shrink,
filesystems may be able to free memory when their inodes are cleared.
As free_page() updates nr_free_pages anyway, maybe try_to_free_pages
shouldn't bother returning anything, and the caller should just recheck to see
how many pages are now free? Also, try_to_free_page seems to return true only
if it has freed SWAP_CLUSTER_MAX pages, isn't that also a problem?

Looking at it again as I just have, and checking the comment at the top of
swap.c, it seems either the code or the documentation or me is wrong :)
low_on_memory goes true when the memory drops below freepages.min, but doesn't
seem to go false again until memory goes above freepages.high. The comment
in swap.c about about only allowing atomic allocations below freepages.min
doesn't seem right either, unless atomic != GFP_ATOMIC, as get_free_pages
allows GFP_MED as well.

What's the difference between SWAP_CLUSTER_MAX, page_cluster, and
pager_daemon.swap_cluster? My brain hurts..

Cheers,
Steve

-- 

- 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/