Re: [PATCH] remove compaction from kswapd

[Andrea Arcangeli <aarcange@redhat.com>]

Hi Andrew,

On Wed, Mar 09, 2011 at 02:17:18PM -0800, Andrew Morton wrote:
> On Wed, 2 Mar 2011 14:25:42 +0000
> Mel Gorman <mel@csn.ul.ie> wrote:
> 
> > mm: compaction: Prevent kswapd compacting memory to reduce CPU usage
> > 
> > This patch reverts [5a03b051: thp: use compaction in kswapd for GFP_ATOMIC
> > order > 0] due to reports stating that kswapd CPU usage was higher
> > and IRQs were being disabled more frequently. This was reported at
> > http://www.spinics.net/linux/fedora/alsa-user/msg09885.html .
> 
> OK, I grabbed this.
> 
> I made a number of changelog changes:
> 
> - Rewrote it as From: Andrea (correct?)
> 
> - Replaced your acked-by with signed-off-by, as you were on the
>   delivery path
> 
> - Hunted down Arthur's email address and added his reported-by and
>   tested-by.

So far so good.

> - Added cc:stable, as it's a bit late for 2.6.38.  The intention
>   being that we put this into 2.6.38.1 after it has cooked in 2.6.39-rcX
>   for a while.  OK?

That's ok with me. It's unfortunate the only two workloads that
triggers this weren't trivial setups and it was found after quite some
time after being introduced (if it was obvious for all workloads, it
wouldn't have gotten there after all, but this also makes it no big
deal if this is only applied in 2.6.38.1 for the same reason).

I think the fundamental issue with compaction is that its searches are
not SWAP_CLUSTER_MAX things, but it goes all the way through the zone
from top to bottom and bottom to top, until the two scans meet in the
middle. So invoking it just once for allocation in direct compaction
(during alloc_pages slow path) is enough. Keeping invoking it in
kswapd (even if at lower rate with my last patch as an attempt to fix
it without removing compaction from kswapd) is probably being
overkill. Maybe kswapd should have a comapction "incremental" mode
that does a SWAP_CLUSTER_MAX thing. Maybe we shouldn't do it from
kswapd either.

We clearly we need a bit more time to sort this out, and in the
meantime returning to the 2.6.37 logic in kswapd of 2.6.38.1 is good
idea and safe.

As opposed we could retain commit
c5a73c3d55be1faadba35b41a862e036a3b12ddb introduced together with the
problematic commit. Commit c5a73c3d55be1faadba35b41a862e036a3b12ddb
should help with the kernel stack allocation during high VM pressure,
without apparently hurting anything. That is somewhat safer than the
kswapd part because it doesn't affect kswapd globally but just the
thread allocating and it's surely not going to insist much invoking
compaction in the background.

Thanks a lot,
Andrea

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>