> I am somewhat concerned about this part of your patch:
>
> --------------
> if (buffer_over_borrow() || pgcache_over_borrow())
> state = 0;
> + if (atomic_read(&nr_async_pages) > pager_daemon.swap_cluster /
> 2)
> + shrink_mmap(i, gfp_mask);
> ------------------
>
> I have tried this patch, and I didn't experience any problems with it.
> But, as somebody (Andrea, I think) pointed out, do_try_to_free_page
> should return as soon as it frees one page; your patch breaks that
> behaviour, doesn't it? Somehow it seems like a hack that fixes the
> symptom instead of the problem.
Without this part of the patch do_try_to_free_page() can keep on
lingering in swap_out() _without_ freeing any page at all! The
if test can only succeed when we're in swap_out() and _not_
freeing pages normally.
> Isn't the real problem that the state in do_try_to_free_page (DTTFP) is
> too simple? I think that must be true if DTTFP gets stuck swapping and
> never tries shrink_mmap, because it does not know when to go back to
> state=0.
> Does that sound correct?
No, do_try_to_free_page() should NOT switch back to state = 0
when swapping stuff out is succesful and there is a reasonably
small amount of cache. Believe me on this one, I have tried it
and it sucks eggs...
> Here is an idea for how to fix your patch to free only one page
> minimum. (I haven't tried to compile it). It is a bit ugly...
If nr_async_pages > 0, then we are in one of the swap_out()
modes and not freeing memory by ourselves.
Besides, it doesn't matter how many pages do_try_to_free_page()
frees because kswapd will terminate when there are enough pages
or when time's up. The return value from dttfp isn't really used
to count anything, so nothing depends on that...
cheers,
Rik -- the flu hits, the flu hits, the flu hits -- MORE
+-------------------------------------------------------------------+
| Linux memory management tour guide. H.H.vanRiel@phys.uu.nl |
| Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ |
+-------------------------------------------------------------------+
-
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/