Messages in this thread | | | Date | Tue, 22 Feb 2011 20:43:25 +0100 | From | Andrea Arcangeli <> | Subject | Re: [Alsa-user] new source of MIDI playback slow-down identified - 5a03b051ed87e72b959f32a86054e1142ac4cf55 thp: use compaction in kswapd for GFP_ATOMIC order > 0 |
| |
On Wed, Feb 23, 2011 at 04:17:44AM +1030, Arthur Marsh wrote: > OK, these patches applied together against upstream didn't cause a crash > but I did observe: > > significant slowdowns of MIDI playback (moreso than in previous cases, > and with less than 20 Meg of swap file in use); > > kswapd0 sharing equal top place in CPU usage at times (e.g. 20 percent). > > If I should try only one of the patches or something else entirely, > please let me know.
For Mel: with z1, kswapd used only 0.1-3.9 percent of CPU while he loaded other applications.
We may need a way to put kswapd in all uncompactable mode to solve this, logic 3 just trying not to disable the all unreclaimable logic seems not enough. I.e. if compact_zone_order doesn't return COMPACT_COMPLETE, stop the compaction loop in kswapd. Then we can put back in the COMPACT_MODE_KSWAPD return COMPACT_CONTINUE in compact_finished as the caller will throttle it (and it won't run more than one scan before putting kswapd to sleep in all uncompactable mode).
| |