From: Simon Jeons <simon.jeons@gmail.com>
To: Zlatko Calusic <zcalusic@bitsync.net>
Cc: Mel Gorman <mgorman@suse.de>,
Andrew Morton <akpm@linux-foundation.org>,
Jiri Slaby <jslaby@suse.cz>,
Valdis Kletnieks <Valdis.Kletnieks@vt.edu>,
Rik van Riel <riel@redhat.com>,
Johannes Weiner <hannes@cmpxchg.org>,
dormando <dormando@rydia.net>,
Satoru Moriya <satoru.moriya@hds.com>,
Michal Hocko <mhocko@suse.cz>, Linux-MM <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/10] Reduce system disruption due to kswapd V2
Date: Mon, 22 Apr 2013 14:43:35 +0800 [thread overview]
Message-ID: <5174DC17.6000809@gmail.com> (raw)
In-Reply-To: <5174DA8F.2020400@bitsync.net>
Hi Zlatko,
On 04/22/2013 02:37 PM, Zlatko Calusic wrote:
> On 12.04.2013 22:07, Zlatko Calusic wrote:
>> On 12.04.2013 21:40, Mel Gorman wrote:
>>> On Thu, Apr 11, 2013 at 10:55:13PM +0200, Zlatko Calusic wrote:
>>>> On 09.04.2013 13:06, Mel Gorman wrote:
>>>> <SNIP>
>>>>
>>>> - The only slightly negative thing I observed is that with the patch
>>>> applied kswapd burns 10x - 20x more CPU. So instead of about 15
>>>> seconds, it has now spent more than 4 minutes on one particular
>>>> machine with a quite steady load (after about 12 days of uptime).
>>>> Admittedly, that's still nothing too alarming, but...
>>>>
>>>
>>> Would you happen to know what circumstances trigger the higher CPU
>>> usage?
>>>
>>
>> Really nothing special. The server is lightly loaded, but it does enough
>> reading from the disk so that pagecache is mostly populated and page
>> reclaiming is active. So, kswapd is no doubt using CPU time gradually,
>> nothing extraordinary.
>>
>> When I sent my reply yesterday, the server uptime was 12 days, and
>> kswapd had accumulated 4:28 CPU time. Now, approx 24 hours later (13
>> days uptime):
>>
>> root 23 0.0 0.0 0 0 ? S Mar30 4:52
>> [kswapd0]
>>
>> I will apply your v3 series soon and see if there's any improvement wrt
>> CPU usage, although as I said I don't see that as a big issue. It's
>> still only 0.013% of available CPU resources (dual core CPU).
>>
>
> JFTR, v3 kswapd uses about 15% more CPU time than v2. 2:50 kswapd CPU
> time after 6 days 14h uptime.
>
> And find attached another debugging graph that shows how ANON pages
> are privileged in the ZONE_NORMAL on a 4GB machine. Take notice that
> the number of pages in the ZONE_DMA32 is scaled (/5) to fit the graph
> nicely.
>
Could you tell me how you draw this picture?
--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Simon Jeons <simon.jeons@gmail.com>
To: Zlatko Calusic <zcalusic@bitsync.net>
Cc: Mel Gorman <mgorman@suse.de>,
Andrew Morton <akpm@linux-foundation.org>,
Jiri Slaby <jslaby@suse.cz>,
Valdis Kletnieks <Valdis.Kletnieks@vt.edu>,
Rik van Riel <riel@redhat.com>,
Johannes Weiner <hannes@cmpxchg.org>,
dormando <dormando@rydia.net>,
Satoru Moriya <satoru.moriya@hds.com>,
Michal Hocko <mhocko@suse.cz>, Linux-MM <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/10] Reduce system disruption due to kswapd V2
Date: Mon, 22 Apr 2013 14:43:35 +0800 [thread overview]
Message-ID: <5174DC17.6000809@gmail.com> (raw)
In-Reply-To: <5174DA8F.2020400@bitsync.net>
Hi Zlatko,
On 04/22/2013 02:37 PM, Zlatko Calusic wrote:
> On 12.04.2013 22:07, Zlatko Calusic wrote:
>> On 12.04.2013 21:40, Mel Gorman wrote:
>>> On Thu, Apr 11, 2013 at 10:55:13PM +0200, Zlatko Calusic wrote:
>>>> On 09.04.2013 13:06, Mel Gorman wrote:
>>>> <SNIP>
>>>>
>>>> - The only slightly negative thing I observed is that with the patch
>>>> applied kswapd burns 10x - 20x more CPU. So instead of about 15
>>>> seconds, it has now spent more than 4 minutes on one particular
>>>> machine with a quite steady load (after about 12 days of uptime).
>>>> Admittedly, that's still nothing too alarming, but...
>>>>
>>>
>>> Would you happen to know what circumstances trigger the higher CPU
>>> usage?
>>>
>>
>> Really nothing special. The server is lightly loaded, but it does enough
>> reading from the disk so that pagecache is mostly populated and page
>> reclaiming is active. So, kswapd is no doubt using CPU time gradually,
>> nothing extraordinary.
>>
>> When I sent my reply yesterday, the server uptime was 12 days, and
>> kswapd had accumulated 4:28 CPU time. Now, approx 24 hours later (13
>> days uptime):
>>
>> root 23 0.0 0.0 0 0 ? S Mar30 4:52
>> [kswapd0]
>>
>> I will apply your v3 series soon and see if there's any improvement wrt
>> CPU usage, although as I said I don't see that as a big issue. It's
>> still only 0.013% of available CPU resources (dual core CPU).
>>
>
> JFTR, v3 kswapd uses about 15% more CPU time than v2. 2:50 kswapd CPU
> time after 6 days 14h uptime.
>
> And find attached another debugging graph that shows how ANON pages
> are privileged in the ZONE_NORMAL on a 4GB machine. Take notice that
> the number of pages in the ZONE_DMA32 is scaled (/5) to fit the graph
> nicely.
>
Could you tell me how you draw this picture?
next prev parent reply other threads:[~2013-04-22 6:43 UTC|newest]
Thread overview: 83+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-09 11:06 [PATCH 0/10] Reduce system disruption due to kswapd V2 Mel Gorman
2013-04-09 11:06 ` Mel Gorman
2013-04-09 11:06 ` [PATCH 01/10] mm: vmscan: Limit the number of pages kswapd reclaims at each priority Mel Gorman
2013-04-09 11:06 ` Mel Gorman
2013-04-09 13:27 ` Michal Hocko
2013-04-09 13:27 ` Michal Hocko
2013-04-10 6:47 ` Kamezawa Hiroyuki
2013-04-10 6:47 ` Kamezawa Hiroyuki
2013-04-09 11:06 ` [PATCH 02/10] mm: vmscan: Obey proportional scanning requirements for kswapd Mel Gorman
2013-04-09 11:06 ` Mel Gorman
2013-04-10 7:16 ` Kamezawa Hiroyuki
2013-04-10 7:16 ` Kamezawa Hiroyuki
2013-04-10 14:08 ` Mel Gorman
2013-04-10 14:08 ` Mel Gorman
2013-04-11 0:14 ` Kamezawa Hiroyuki
2013-04-11 0:14 ` Kamezawa Hiroyuki
2013-04-11 9:09 ` Mel Gorman
2013-04-11 9:09 ` Mel Gorman
2013-04-09 11:06 ` [PATCH 03/10] mm: vmscan: Flatten kswapd priority loop Mel Gorman
2013-04-09 11:06 ` Mel Gorman
2013-04-10 7:47 ` Kamezawa Hiroyuki
2013-04-10 7:47 ` Kamezawa Hiroyuki
2013-04-10 13:29 ` Mel Gorman
2013-04-10 13:29 ` Mel Gorman
2013-04-12 2:45 ` Rik van Riel
2013-04-12 2:45 ` Rik van Riel
2013-04-09 11:06 ` [PATCH 04/10] mm: vmscan: Decide whether to compact the pgdat based on reclaim progress Mel Gorman
2013-04-09 11:06 ` Mel Gorman
2013-04-10 8:05 ` Kamezawa Hiroyuki
2013-04-10 8:05 ` Kamezawa Hiroyuki
2013-04-10 13:57 ` Mel Gorman
2013-04-10 13:57 ` Mel Gorman
2013-04-12 2:46 ` Rik van Riel
2013-04-12 2:46 ` Rik van Riel
2013-04-09 11:07 ` [PATCH 05/10] mm: vmscan: Do not allow kswapd to scan at maximum priority Mel Gorman
2013-04-09 11:07 ` Mel Gorman
2013-04-09 11:07 ` [PATCH 06/10] mm: vmscan: Have kswapd writeback pages based on dirty pages encountered, not priority Mel Gorman
2013-04-09 11:07 ` Mel Gorman
2013-04-12 2:51 ` Rik van Riel
2013-04-12 2:51 ` Rik van Riel
2013-04-09 11:07 ` [PATCH 07/10] mm: vmscan: Block kswapd if it is encountering pages under writeback Mel Gorman
2013-04-09 11:07 ` Mel Gorman
2013-04-12 2:54 ` Rik van Riel
2013-04-12 2:54 ` Rik van Riel
2013-04-09 11:07 ` [PATCH 08/10] mm: vmscan: Have kswapd shrink slab only once per priority Mel Gorman
2013-04-09 11:07 ` Mel Gorman
2013-04-09 11:07 ` [PATCH 09/10] mm: vmscan: Check if kswapd should writepage once per pgdat scan Mel Gorman
2013-04-09 11:07 ` Mel Gorman
2013-04-09 11:07 ` [PATCH 10/10] mm: vmscan: Move logic from balance_pgdat() to kswapd_shrink_zone() Mel Gorman
2013-04-09 11:07 ` Mel Gorman
2013-04-12 2:56 ` Rik van Riel
2013-04-12 2:56 ` Rik van Riel
2013-04-09 17:27 ` [PATCH 0/10] Reduce system disruption due to kswapd V2 Christoph Lameter
2013-04-09 17:27 ` Christoph Lameter
2013-04-10 14:14 ` Mel Gorman
2013-04-10 14:14 ` Mel Gorman
2013-04-10 22:28 ` dormando
2013-04-10 22:28 ` dormando
2013-04-10 23:46 ` KOSAKI Motohiro
2013-04-10 23:46 ` KOSAKI Motohiro
2013-04-11 9:10 ` Mel Gorman
2013-04-11 9:10 ` Mel Gorman
2013-04-11 20:13 ` Michal Hocko
2013-04-11 20:13 ` Michal Hocko
2013-04-11 20:55 ` Zlatko Calusic
2013-04-11 20:55 ` Zlatko Calusic
2013-04-12 19:40 ` Mel Gorman
2013-04-12 19:40 ` Mel Gorman
2013-04-12 19:52 ` Mel Gorman
2013-04-12 19:52 ` Mel Gorman
2013-04-12 20:07 ` Zlatko Calusic
2013-04-12 20:07 ` Zlatko Calusic
2013-04-12 20:41 ` Mel Gorman
2013-04-12 20:41 ` Mel Gorman
2013-04-12 21:14 ` Zlatko Calusic
2013-04-12 21:14 ` Zlatko Calusic
2013-04-22 6:37 ` Zlatko Calusic
2013-04-22 6:43 ` Simon Jeons [this message]
2013-04-22 6:43 ` Simon Jeons
2013-04-22 6:54 ` Zlatko Calusic
2013-04-22 6:54 ` Zlatko Calusic
2013-04-22 7:12 ` Simon Jeons
2013-04-22 7:12 ` Simon Jeons
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5174DC17.6000809@gmail.com \
--to=simon.jeons@gmail.com \
--cc=Valdis.Kletnieks@vt.edu \
--cc=akpm@linux-foundation.org \
--cc=dormando@rydia.net \
--cc=hannes@cmpxchg.org \
--cc=jslaby@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mhocko@suse.cz \
--cc=riel@redhat.com \
--cc=satoru.moriya@hds.com \
--cc=zcalusic@bitsync.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.