Re: [PATCH] mm,vmscan: compact memory from kswapd when lots of memory free already

[Vlastimil Babka <vbabka@suse.cz>]

On 02/23/2016 04:50 AM, Rik van Riel wrote:
> If kswapd is woken up for a higher order allocation, for example
> from alloc_skb, but the system already has lots of memory free,
> kswapd_shrink_zone will rightfully decide kswapd should not free
> any more memory.
>
> However, at that point kswapd should proceed to compact memory, on
> behalf of alloc_skb or others.
>
> Currently kswapd will only compact memory if it first freed memory,
> leading kswapd to never compact memory when there is already lots of
> memory free.
>
> On my home system, that lead to kswapd occasionally using up to 5%
> CPU time, with many man wakeups from alloc_skb, and kswapd never
> doing anything to relieve the situation that caused it to be woken
> up.

Hi,

I've proposed replacing kswapd compaction with kcompactd, so this hunk 
is gone completely in mmotm. This imperfect comparison was indeed one of 
the things I've noted, but it's not all:

http://marc.info/?l=linux-kernel&m=145493881908394&w=2

> Going ahead with compaction when kswapd did not attempt to reclaim
> any memory, and as a consequence did not reclaim any memory, is the
> right thing to do in this situation.
>
> Signed-off-by: Rik van Riel <riel@redhat.com>
> ---
>   mm/vmscan.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 71b1c29948db..9566a04b9759 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -3343,7 +3343,7 @@ static unsigned long balance_pgdat(pg_data_t *pgdat, int order,
>   		 * Compact if necessary and kswapd is reclaiming at least the
>   		 * high watermark number of pages as requsted
>   		 */
> -		if (pgdat_needs_compaction && sc.nr_reclaimed > nr_attempted)
> +		if (pgdat_needs_compaction && sc.nr_reclaimed >= nr_attempted)
>   			compact_pgdat(pgdat, order);
>
>   		/*
>