Messages in this thread | | | Subject | Re: [PATCH] mm,vmscan: compact memory from kswapd when lots of memory free already | From | Rik van Riel <> | Date | Tue, 23 Feb 2016 10:39:56 -0500 |
| |
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.
[unhandled content-type:application/pgp-signature] | |