linux-kernel - Re: [PATCH v2] mm: Warn about costly page allocation

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] [day] [month] [year] [list]

Message-ID: <20120712030039.GA29650@bbox>
Date:	Thu, 12 Jul 2012 12:00:39 +0900
From:	Minchan Kim <minchan@...nel.org>
To:	David Rientjes <rientjes@...gle.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	Rik van Riel <riel@...hat.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Mel Gorman <mgorman@...e.de>,
	Johannes Weiner <hannes@...xchg.org>,
	Kamezawa Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
Subject: Re: [PATCH v2] mm: Warn about costly page allocation

On Wed, Jul 11, 2012 at 07:33:41PM -0700, David Rientjes wrote:
> On Thu, 12 Jul 2012, Minchan Kim wrote:
> 
> > Agreed and that's why I suggested following patch.
> > It's not elegant but at least, it could attract interest of configuration
> > people and they could find a regression during test phase.
> > This description could be improved later by writing new documenation which
> > includes more detailed story and method for capturing high order allocation
> > by ftrace once we see regression report.
> > 
> > At the moment, I would like to post this patch, simply.
> > (Of course, I hope fluent native people will correct a sentence. :) )
> > 
> > Any objections, Andrew, David?
> > 
> 
> There are other config options like CONFIG_SLOB that are used for a very 
> small memory footprint on systems like this.  We used to have 
> CONFIG_EMBEDDED to suggest options like this but that has since been 
> renamed as CONFIG_EXPERT and has become obscured.
> 
> If size is really the only difference, I would think that people who want 
> the smallest kernel possible would be doing allnoconfig and then 
> selectively enabling what they need, so defconfig isn't really relevant 
> here.  And it's very difficult for an admin to know whether or not they 
> "care about high-order allocations."
> 
> I'd reconsider disabling compaction by default unless there are other 
> considerations that haven't been mentioned.

I agree but it doesn't matter with current problem.
The point of current problem is to let admin know dangerous of regression
about high order allocation before releasing the product.

Although we enable it by defaut, he can change it with "N" unless he
knows removing of lumpy reclaim.

> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@...ck.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@...ck.org"> email@...ck.org </a>

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