On Wed, 11 Jan 2012 07:25:20 +0400 "Nikolay S." [off-list ref] wrote:

__ ____., 10/01/2012 __ 14:33 -0800, Andrew Morton __________:

quoted

On Tue, 27 Dec 2011 13:56:58 +0900
KAMEZAWA Hiroyuki [off-list ref] wrote:

quoted

Hmm, if I understand correctly,

 - dd's speed down is caused by kswapd's cpu consumption.
 - kswapd's cpu consumption is enlarged by shrink_slab() (by perf)
 - kswapd can't stop because NORMAL zone is small.
 - memory reclaim speed is enough because dd can't get enough cpu.

I wonder reducing to call shrink_slab() may be a help but I'm not sure
where lock conention comes from...

Nikolay, it sounds as if this problem has only recently started
happening?  Was 3.1 OK?

If so, we should work out what we did post-3.1 to cause this.

Yes, 3.1. was ok.
Recently I have upgraded to 3.2, and I can not reproduce the problem.
I'm now at 5 days uptime, the machine usage pattern, the software - all
the same, but the problem is not visible anymore:

  PID USER      S %CPU %MEM    TIME+  SWAP COMMAND
14822 nowhere   R   30  0.2   0:01.52  10m dd
  416 root      S    7  0.0   6:26.72    0 kswapd0

(also, kswapd run time after 5 days is only 6,5 seconds, whereas with
-rc5 it was 22 seconds after 5 days).

I can provide similar traces to see what has changed in kswapd's
activities (if it is of any value)

OK, thanks for the followup.  I suppose we assume this is fixed unless
someone reports it in 3.2.

--
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>