Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: high kswapd CPU usage when executing binaries from NFS w/ CMA and COMPACTION
40 views
Skip to first unread message
Mel Gorman
Dec 4, 2013, 8:10:01 AM12/4/13
to
On Tue, Dec 03, 2013 at 06:30:28PM -0800, Florian Fainelli wrote:
> Hi all,
>
> I am experiencing high kswapd CPU usage on an ARMv7 system running
> 3.8.13 when executing relatively large binaries from NFS. When this
> happens kswapd consumes around 55-60% CPU usage and the applications
> takes a huge time to load.
>
There were a number of changes made related to how and when kswapd
stalls, particularly when pages are dirty. Brief check confirms that
git log v3.8..v3.12 --pretty=one --author "Mel Gorman" mm/vmscan.c
NFS dirty pages are problematic for compaction as dirty pages cannot be
migrated until cleaned. I'd suggest checking if current mainline suffers
the same problem and if not, focus on patches related to dirty page
handling and kswapd throttling in mm/vmscan.c as backport candidates.
--
Mel Gorman
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
> Hi all,
>
> I am experiencing high kswapd CPU usage on an ARMv7 system running
> 3.8.13 when executing relatively large binaries from NFS. When this
> happens kswapd consumes around 55-60% CPU usage and the applications
> takes a huge time to load.
>
There were a number of changes made related to how and when kswapd
stalls, particularly when pages are dirty. Brief check confirms that
git log v3.8..v3.12 --pretty=one --author "Mel Gorman" mm/vmscan.c
NFS dirty pages are problematic for compaction as dirty pages cannot be
migrated until cleaned. I'd suggest checking if current mainline suffers
the same problem and if not, focus on patches related to dirty page
handling and kswapd throttling in mm/vmscan.c as backport candidates.
--
Mel Gorman
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Florian Fainelli
Dec 6, 2013, 6:00:02 PM12/6/13
to
2013/12/4 Mel Gorman <mgo...@suse.de>:
problem, although kswapd usage dropped considerably (by half
approximately). Will keep you updated once I have properly tested
current mainline on my platform. Thanks!
--
Florian
> On Tue, Dec 03, 2013 at 06:30:28PM -0800, Florian Fainelli wrote:
>> Hi all,
>>
>> I am experiencing high kswapd CPU usage on an ARMv7 system running
>> 3.8.13 when executing relatively large binaries from NFS. When this
>> happens kswapd consumes around 55-60% CPU usage and the applications
>> takes a huge time to load.
>>
>
> There were a number of changes made related to how and when kswapd
> stalls, particularly when pages are dirty. Brief check confirms that
>
> git log v3.8..v3.12 --pretty=one --author "Mel Gorman" mm/vmscan.c
>
> NFS dirty pages are problematic for compaction as dirty pages cannot be
> migrated until cleaned. I'd suggest checking if current mainline suffers
> the same problem and if not, focus on patches related to dirty page
> handling and kswapd throttling in mm/vmscan.c as backport candidates.
I have just backported these patches to 3.8.13 and am still seeing the
>> Hi all,
>>
>> I am experiencing high kswapd CPU usage on an ARMv7 system running
>> 3.8.13 when executing relatively large binaries from NFS. When this
>> happens kswapd consumes around 55-60% CPU usage and the applications
>> takes a huge time to load.
>>
>
> There were a number of changes made related to how and when kswapd
> stalls, particularly when pages are dirty. Brief check confirms that
>
> git log v3.8..v3.12 --pretty=one --author "Mel Gorman" mm/vmscan.c
>
> NFS dirty pages are problematic for compaction as dirty pages cannot be
> migrated until cleaned. I'd suggest checking if current mainline suffers
> the same problem and if not, focus on patches related to dirty page
> handling and kswapd throttling in mm/vmscan.c as backport candidates.
problem, although kswapd usage dropped considerably (by half
approximately). Will keep you updated once I have properly tested
current mainline on my platform. Thanks!
--
Florian
0 new messages