Messages in this thread | | | Date | Wed, 25 Jul 2012 14:24:54 -0400 | From | Rik van Riel <> | Subject | Re: [PATCH -mm] remove __GFP_NO_KSWAPD |
| |
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.
| |