On Tue, 2016-02-23 at 10:18 +0100, Vlastimil Babka wrote: > 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
Never mind my patch, then. Your solution is nicer, and already in -mm :) -- All Rights Reversed.
signature.asc
Description: This is a digitally signed message part
