linux-kernel - Re: [PATCH -mm] remove __GFP_NO

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 25 Jul 2012 08:34:22 +0900
From:	Minchan Kim <minchan@...nel.org>
To:	Rik van Riel <riel@...hat.com>
Cc:	linux-mm@...ck.org, Andrea Arcangeli <aarcange@...hat.com>,
	lkml <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Mel Gorman <mel@....ul.ie>
Subject: Re: [PATCH -mm] remove __GFP_NO_KSWAPD

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.

> 
> Signed-off-by: Rik van Riel <riel@...hat.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. :)

> ---
> 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.

-- 
Kind regards,
Minchan Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/