linux-kernel - Re: [PATCH 6/8] mm: compaction: Perform a faster scan in try_to_compact

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]

Message-ID: <20101119111629.GE28613@csn.ul.ie>
Date:	Fri, 19 Nov 2010 11:16:30 +0000
From:	Mel Gorman <mel@....ul.ie>
To:	Andrea Arcangeli <aarcange@...hat.com>
Cc:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Rik van Riel <riel@...hat.com>,
	Johannes Weiner <hannes@...xchg.org>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 6/8] mm: compaction: Perform a faster scan in
	try_to_compact_pages()

On Thu, Nov 18, 2010 at 08:08:39PM +0100, Andrea Arcangeli wrote:
> On Thu, Nov 18, 2010 at 06:50:46PM +0000, Mel Gorman wrote:
> > For THP in general, I think we can abuse __GFP_NO_KSWAPD. For other callers,
> > I'm not sure it's fair to push the responsibility of async/sync to them. We
> > don't do it for reclaim for example and I'd worry the wrong decisions would
> > be made or that they'd always select async for "performance" and then bitch
> > about an allocation failure.
> 
> Ok, let's leave the __GFP and let's stick to the simplest for now
> without alloc_pages caller knowledge.
> 

Ok.

> > My only whinge about the lack of reclaimcompact_zone_order is that it
> > makes it harder to even contemplate lumpy compaction in the future but
> > it could always be reintroduced if absolutely necessary.
> 
> Ok. I don't know the plan of lumpy compaction and that's probably why
> I didn't appreciate it...
> 

You're not a mind-reader :) . What it'd get should be a reduction in
scanning rates but there are other means that should be considered too.

> So my preference as usual would be to remove lumpy. BTW, everything up
> to patch 3 included should work fine with THP and solve my problem
> with lumpy, thanks!
> 

Great. I'd still like to push the rest of the series if it can be shown the
latencies decrease each time. It'll reduce the motivation for introducing
GFP flags to avoid compaction overhead.

> > GFP flags would be my last preference. 
> 
> yep. I'm just probably too paranoid at being lowlatency in the
> hugepage allocation because I know it's the only spot where THP may
> actually introduce a regression for short lived tasks if we do too
> much work to create the hugepage. OTOH even for short lived allocation
> on my westmire a bzero(1g) runs 250% (not 50% faster like in the older
> hardware I was using) faster just thanks to the page being huge and
> I'm talking about super short lived allocation here (the troublesome
> one if we spend too much time in compaction and reclaim before
> failing). Plus it only makes a difference when hugepages are so spread
> across the whole system and it's still doing purely short lived
> allocations. So again let's worry about the GFP flag later if
> something...

Sounds like a plan.

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab
--
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/