From: Rik van Riel <riel@redhat.com>
To: Minchan Kim <minchan@kernel.org>
Cc: linux-mm@kvack.org, Andrea Arcangeli <aarcange@redhat.com>,
lkml <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Mel Gorman <mel@csn.ul.ie>
Subject: Re: [PATCH -mm] remove __GFP_NO_KSWAPD
Date: Wed, 25 Jul 2012 14:24:54 -0400 [thread overview]
Message-ID: <501039F6.7010702@redhat.com> (raw)
In-Reply-To: <20120724233422.GB14411@bbox>
On 07/24/2012 07:34 PM, Minchan Kim wrote:
> Hi Rik,
>
> On Tue, Jul 24, 2012 at 11:12:22AM -0400, Rik van Riel wrote:
>> When transparent huge pages were introduced, memory compaction and
>> swap storms were an issue, and the kernel had to be careful to not
>> make THP allocations cause pageout or compaction.
>>
>> Now that we have working compaction deferral, kswapd is smart enough
>> to invoke compaction and the quadratic behaviour around isolate_free_pages
>> has been fixed, it should be safe to remove __GFP_NO_KSWAPD.
>
> Could you point out specific patches you mentiond which makes kswapd/compaction
> smart? It will make description very clear.
That could be a list of 50+ patches, merged over the
last two or so years.
In other words, such a large amount of data that it
is unlikely to clarify the discussion...
>> Signed-off-by: Rik van Riel <riel@redhat.com>
>
> I support it because I had a concern about that flags which is likely to be
> used by other subsystems without careful thinking when the flag was introduced.
> It's proved by mtd_kmalloc_up_to which was merged with sneaking without catching
> from mm guys's eyes. When I read comment of that function, it seems to be proper
> usage but I don't like it because it requries users of mm to know mm internal
> like kswapd. So it should be avoided if possible.
>
> Plus, it means you need to fix it with show_gfp_flags. :)
Ohh, a place I forgot to grep!
I'll send in an incremental patch right now.
>> ---
>> This has been running fine on my system for a while, but my system
>> only has 12GB and moderate memory pressure. I propose we keep this
>> in -mm and -next for a while, and merge it for 3.7 if nobody complains.
>
> Yes. it should be very careful.
> I guess Mel and Andrea would have opinions and benchmark.
It's not as much benchmarks that I am worried about,
but somebody running something unexpected on their
system.
--
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: Rik van Riel <riel@redhat.com>
To: Minchan Kim <minchan@kernel.org>
Cc: linux-mm@kvack.org, Andrea Arcangeli <aarcange@redhat.com>,
lkml <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Mel Gorman <mel@csn.ul.ie>
Subject: Re: [PATCH -mm] remove __GFP_NO_KSWAPD
Date: Wed, 25 Jul 2012 14:24:54 -0400 [thread overview]
Message-ID: <501039F6.7010702@redhat.com> (raw)
In-Reply-To: <20120724233422.GB14411@bbox>
On 07/24/2012 07:34 PM, Minchan Kim wrote:
> Hi Rik,
>
> On Tue, Jul 24, 2012 at 11:12:22AM -0400, Rik van Riel wrote:
>> When transparent huge pages were introduced, memory compaction and
>> swap storms were an issue, and the kernel had to be careful to not
>> make THP allocations cause pageout or compaction.
>>
>> Now that we have working compaction deferral, kswapd is smart enough
>> to invoke compaction and the quadratic behaviour around isolate_free_pages
>> has been fixed, it should be safe to remove __GFP_NO_KSWAPD.
>
> Could you point out specific patches you mentiond which makes kswapd/compaction
> smart? It will make description very clear.
That could be a list of 50+ patches, merged over the
last two or so years.
In other words, such a large amount of data that it
is unlikely to clarify the discussion...
>> Signed-off-by: Rik van Riel <riel@redhat.com>
>
> I support it because I had a concern about that flags which is likely to be
> used by other subsystems without careful thinking when the flag was introduced.
> It's proved by mtd_kmalloc_up_to which was merged with sneaking without catching
> from mm guys's eyes. When I read comment of that function, it seems to be proper
> usage but I don't like it because it requries users of mm to know mm internal
> like kswapd. So it should be avoided if possible.
>
> Plus, it means you need to fix it with show_gfp_flags. :)
Ohh, a place I forgot to grep!
I'll send in an incremental patch right now.
>> ---
>> This has been running fine on my system for a while, but my system
>> only has 12GB and moderate memory pressure. I propose we keep this
>> in -mm and -next for a while, and merge it for 3.7 if nobody complains.
>
> Yes. it should be very careful.
> I guess Mel and Andrea would have opinions and benchmark.
It's not as much benchmarks that I am worried about,
but somebody running something unexpected on their
system.
next prev parent reply other threads:[~2012-07-25 18:26 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-24 15:12 [PATCH -mm] remove __GFP_NO_KSWAPD Rik van Riel
2012-07-24 15:12 ` Rik van Riel
2012-07-24 23:34 ` Minchan Kim
2012-07-24 23:34 ` Minchan Kim
2012-07-25 18:24 ` Rik van Riel [this message]
2012-07-25 18:24 ` Rik van Riel
2012-07-25 18:51 ` [PATCH -mm] remove __GFP_NO_KSWAPD fixes Rik van Riel
2012-07-25 18:51 ` Rik van Riel
2012-07-25 23:36 ` Minchan Kim
2012-07-25 23:36 ` Minchan Kim
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=501039F6.7010702@redhat.com \
--to=riel@redhat.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mel@csn.ul.ie \
--cc=minchan@kernel.org \
/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.