>So, what we are left with is just an unpredictable performance change,
>not a GFP_ATOMIC lockup.
_Exactly_ ;).
> [..] That will be much easier to tune. kswapd
>still may have to do more than this, though: the last time I did any
>serious performance profiling on the vm stack, it showed up pretty
>clearly that async swapout by kswapd was one of the most important
>factors in sustaining high swapout throughput. If you don't have kswapd
I think some real-world swap-performance can give us some number about
this issue. I believe there will be no need to further change kswapd in
real-world since with 4giga of ram the swap performances won't be
critical. It's true that a swap_out() may stall for some long time if
there is a big chunk of bigmem allocated in the user-MM though. But again
I don't consider this a major problem.
If it would been safe I would just do something like:
do_try_to_free_pages(GFP_KSWAPD | (nr_bigmem_pages ? 0 : GFP_BIGMEM));
but it's not safe because you _can't_ know for sure what the system really
needs (the bigmem pages may be all allocated in userspace and you may want
regular pages and not bigmem pages).
And in general taking lots of regular pages free is a good thing. We won't
have VM pressure if there aren't bigmem pages free.
>acting in that capacity in high memory, we may well see reduced swap
>throughput under load.
Yes. I think the more interesting issue is swap_out that may run for some
long time without go to sleep (I think exactly what just happens with
GFP_DMA).
>However, I guess that is less important on a 4G machine than on, say, my
>laptop. :) It may still be a factor on machines running heavy
Yes, that was exactly my point ;).
Andrea
-
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/