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@xxxxxxxxx> 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@xxxxxxxxxx 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@xxxxxxxxx";> email@xxxxxxxxx </a>