From: Rik van Riel <riel@redhat.com>
To: Andrea Arcangeli <aarcange@redhat.com>
Cc: Mel Gorman <mel@csn.ul.ie>,
linux-mm@kvack.org, lkml <linux-kernel@vger.kernel.org>,
Johannes Weiner <hannes@cmpxchg.org>,
Andrew Morton <akpm@linux-foundation.org>,
Minchan Kim <minchan.kim@gmail.com>,
KOSAKI Motohiro <kosaki.motohiro@gmail.com>
Subject: Re: [PATCH v2 -mm 1/3] mm: reclaim at order 0 when compaction is enabled
Date: Wed, 25 Jan 2012 21:12:34 -0500 [thread overview]
Message-ID: <4F20B692.4080906@redhat.com> (raw)
In-Reply-To: <20120125221632.GL30782@redhat.com>
On 01/25/2012 05:16 PM, Andrea Arcangeli wrote:
> On Wed, Jan 25, 2012 at 10:27:28AM -0500, Rik van Riel wrote:
>> On 01/25/2012 10:00 AM, Mel Gorman wrote:
>>> On Tue, Jan 24, 2012 at 01:21:36PM -0500, Rik van Riel wrote:
>>>> When built with CONFIG_COMPACTION, kswapd does not try to free
>>>> contiguous pages.
>>>
>>> balance_pgdat() gets its order from wakeup_kswapd(). This does not apply
>>> to THP because kswapd does not get woken for THP but it should be woken
>>> up for allocations like jumbo frames or order-1.
>>
>> In the kernel I run at home, I wake up kswapd for THP
>> as well. This is a larger change, which Andrea asked
>> me to delay submitting upstream for a bit.
>>
>> So far there seem to be no ill effects. I'll continue
>> watching for them.
>
> The only problem we had last time when we managed to add compaction in
> kswapd upstream, was a problem of that too high kswapd wakeup
> frequency that kept kswapd spinning at 100% load and destroying
> specsfs performance. It may have been a fundamental problem of
> compaction not being worthwhile to run to generate jumbo frames
> because the cost of migrating memory, copying, flushing ptes
I suspect the problem was much simpler back then. Kswapd
invoked compaction inside the loop, instead of outside the
loop, and there was no throttling at all.
> About THP, it may not give problems for THP because the allocation
> rate is much slower.
> I'm still quite afraid that compaction in kswapd waken by jumbo frames
> may not work well,
THP allocations may be slower, but jumbo frames get freed
again quickly. We do not have to compact memory for every
few jumbo frame allocations, only when the number of packets
in flight is going up...
You are right that it should be tested, though :)
I will look into that.
--
All rights reversed
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2012-01-26 2:13 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-24 18:18 [PATCH v2 -mm 0/3] kswapd vs compaction improvements Rik van Riel
2012-01-24 18:21 ` [PATCH v2 -mm 1/3] mm: reclaim at order 0 when compaction is enabled Rik van Riel
2012-01-25 15:00 ` Mel Gorman
2012-01-25 15:27 ` Rik van Riel
2012-01-25 16:07 ` Mel Gorman
2012-01-25 17:17 ` Rik van Riel
2012-01-25 22:16 ` Andrea Arcangeli
2012-01-26 2:12 ` Rik van Riel [this message]
2012-01-24 18:22 ` [PATCH v2 -mm 2/3] mm: kswapd carefully call compaction Rik van Riel
2012-01-25 15:19 ` Mel Gorman
2012-01-24 18:23 ` [PATCH v2 -mm 3/3] mm: only defer compaction for failed order and higher Rik van Riel
2012-01-25 15:41 ` Mel Gorman
2012-01-25 15:55 ` Rik van Riel
2012-01-25 16:21 ` Mel Gorman
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=4F20B692.4080906@redhat.com \
--to=riel@redhat.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=kosaki.motohiro@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mel@csn.ul.ie \
--cc=minchan.kim@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).