From: Cong Wang <amwang@redhat.com> To: Andrea Arcangeli <aarcange@redhat.com> Cc: David Rientjes <rientjes@google.com>, linux-kernel@vger.kernel.org, Andrew Morton <akpm@linux-foundation.org>, dave@linux.vnet.ibm.com, Mel Gorman <mel@csn.ul.ie>, Benjamin Herrenschmidt <benh@kernel.crashing.org>, Rik van Riel <riel@redhat.com>, Johannes Weiner <hannes@cmpxchg.org>, KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>, linux-mm@kvack.org Subject: Re: [PATCH v2 2/4] mm: make the threshold of enabling THP configurable Date: Thu, 23 Jun 2011 14:51:47 +0800 [thread overview] Message-ID: <4E02E283.3080702@redhat.com> (raw) In-Reply-To: <20110622144057.GW20843@redhat.com> 于 2011年06月22日 22:40, Andrea Arcangeli 写道: > On Wed, Jun 22, 2011 at 07:07:25PM +0800, Cong Wang wrote: >> Actually, if we move this out of kernel, to user-space, everything >> you worried will be solved by just changing the user-space code. >> Just add the following pseudo code into your init script, >> >> if [ $total_memory -lt 512 ] >> then >> echo never> /sys/kernel/mm/transparent_hugepage/enabled >> fi > > By the time this script runs some app may have allocated hugepages > already potentially wasting mbytes of ram and undoing the > min_free_kbytes isn't possible from userland using the kernel > algorithm (it is possible actually but it's not nearly as simple as > the above). I remember there is a way to tell init-scripts to run it as early as possible. :) > > There's no reason to complicate things and involve userland here when > a simple kernel check can get the default right without userland > dependency. Plus if this user really wants THP on 512m of ram he can > still enable it and run hugeadm to enable antifrag too, without the > need of =force. And forcing when PSE is enabled sounds impossible to be > useful (maybe with the except of nopentium being passed to the kernel ;). > > There is no bug here, just send that printk cleanup and if you really > want to save 8k the patch to change the number of hash heads structs > at boot, like for dcache/icache. No other change required. I never said this is a bug, I just don't think it is flexible. ;) > > After you do the above, you can go ahead picking one kernel crashing > bug and fix it, that is more useful than making this 512m thing a > .config variable or anything like that, .config is a nightmare already > so it's probably better not to add anything there. Well, I can't agree with this point. Since we can't persuade each other, I give up. Thanks.
WARNING: multiple messages have this Message-ID (diff)
From: Cong Wang <amwang@redhat.com> To: Andrea Arcangeli <aarcange@redhat.com> Cc: David Rientjes <rientjes@google.com>, linux-kernel@vger.kernel.org, Andrew Morton <akpm@linux-foundation.org>, dave@linux.vnet.ibm.com, Mel Gorman <mel@csn.ul.ie>, Benjamin Herrenschmidt <benh@kernel.crashing.org>, Rik van Riel <riel@redhat.com>, Johannes Weiner <hannes@cmpxchg.org>, KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>, linux-mm@kvack.org Subject: Re: [PATCH v2 2/4] mm: make the threshold of enabling THP configurable Date: Thu, 23 Jun 2011 14:51:47 +0800 [thread overview] Message-ID: <4E02E283.3080702@redhat.com> (raw) In-Reply-To: <20110622144057.GW20843@redhat.com> ao? 2011a1'06ae??22ae?JPY 22:40, Andrea Arcangeli a??e??: > On Wed, Jun 22, 2011 at 07:07:25PM +0800, Cong Wang wrote: >> Actually, if we move this out of kernel, to user-space, everything >> you worried will be solved by just changing the user-space code. >> Just add the following pseudo code into your init script, >> >> if [ $total_memory -lt 512 ] >> then >> echo never> /sys/kernel/mm/transparent_hugepage/enabled >> fi > > By the time this script runs some app may have allocated hugepages > already potentially wasting mbytes of ram and undoing the > min_free_kbytes isn't possible from userland using the kernel > algorithm (it is possible actually but it's not nearly as simple as > the above). I remember there is a way to tell init-scripts to run it as early as possible. :) > > There's no reason to complicate things and involve userland here when > a simple kernel check can get the default right without userland > dependency. Plus if this user really wants THP on 512m of ram he can > still enable it and run hugeadm to enable antifrag too, without the > need of =force. And forcing when PSE is enabled sounds impossible to be > useful (maybe with the except of nopentium being passed to the kernel ;). > > There is no bug here, just send that printk cleanup and if you really > want to save 8k the patch to change the number of hash heads structs > at boot, like for dcache/icache. No other change required. I never said this is a bug, I just don't think it is flexible. ;) > > After you do the above, you can go ahead picking one kernel crashing > bug and fix it, that is more useful than making this 512m thing a > .config variable or anything like that, .config is a nightmare already > so it's probably better not to add anything there. Well, I can't agree with this point. Since we can't persuade each other, I give up. Thanks. -- 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/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2011-06-23 6:53 UTC|newest] Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-06-21 8:10 [PATCH v2 1/4] mm: completely disable THP by transparent_hugepage=0 Amerigo Wang 2011-06-21 8:10 ` Amerigo Wang 2011-06-21 8:10 ` [PATCH v2 2/4] mm: make the threshold of enabling THP configurable Amerigo Wang 2011-06-21 8:10 ` Amerigo Wang 2011-06-21 14:44 ` Dave Hansen 2011-06-21 14:44 ` Dave Hansen 2011-06-21 20:17 ` Dave Hansen 2011-06-21 20:17 ` Dave Hansen 2011-06-22 1:23 ` David Rientjes 2011-06-22 1:23 ` David Rientjes 2011-06-22 3:06 ` Cong Wang 2011-06-22 3:06 ` Cong Wang 2011-06-22 3:29 ` David Rientjes 2011-06-22 3:29 ` David Rientjes 2011-06-22 5:40 ` Cong Wang 2011-06-22 5:40 ` Cong Wang 2011-06-22 6:32 ` David Rientjes 2011-06-22 6:32 ` David Rientjes 2011-06-22 11:07 ` Cong Wang 2011-06-22 11:07 ` Cong Wang 2011-06-22 14:40 ` Andrea Arcangeli 2011-06-22 14:40 ` Andrea Arcangeli 2011-06-23 6:51 ` Cong Wang [this message] 2011-06-23 6:51 ` Cong Wang 2011-06-21 8:10 ` [PATCH 3/4] mm: improve THP printk messages Amerigo Wang 2011-06-21 8:10 ` Amerigo Wang 2011-06-22 1:23 ` David Rientjes 2011-06-22 1:23 ` David Rientjes 2011-06-22 3:04 ` Cong Wang 2011-06-22 3:04 ` Cong Wang 2011-06-21 8:10 ` [PATCH 4/4] mm: introduce no_ksm to disable totally KSM Amerigo Wang 2011-06-21 8:10 ` Amerigo Wang 2011-06-21 13:32 ` Andrea Arcangeli 2011-06-21 13:32 ` Andrea Arcangeli 2011-06-22 3:13 ` Cong Wang 2011-06-22 3:13 ` Cong Wang 2011-06-21 11:52 ` [PATCH v2 1/4] mm: completely disable THP by transparent_hugepage=0 Michal Hocko 2011-06-21 11:52 ` Michal Hocko 2011-06-21 11:58 ` Michal Hocko 2011-06-21 11:58 ` Michal Hocko 2011-06-21 13:30 ` Andrea Arcangeli 2011-06-21 13:30 ` Andrea Arcangeli 2011-06-22 3:11 ` Cong Wang 2011-06-22 3:11 ` Cong Wang 2011-06-22 1:16 ` David Rientjes 2011-06-22 1:16 ` David Rientjes 2011-06-22 3:08 ` Cong Wang 2011-06-22 3:08 ` Cong Wang 2011-06-22 3:24 ` David Rientjes 2011-06-22 3:24 ` David Rientjes 2011-06-22 5:45 ` Cong Wang 2011-06-22 5:45 ` Cong Wang 2011-06-22 6:23 ` David Rientjes 2011-06-22 6:23 ` David Rientjes 2011-06-22 11:08 ` Cong Wang 2011-06-22 11:08 ` Cong Wang
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=4E02E283.3080702@redhat.com \ --to=amwang@redhat.com \ --cc=aarcange@redhat.com \ --cc=akpm@linux-foundation.org \ --cc=benh@kernel.crashing.org \ --cc=dave@linux.vnet.ibm.com \ --cc=hannes@cmpxchg.org \ --cc=kamezawa.hiroyu@jp.fujitsu.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mel@csn.ul.ie \ --cc=riel@redhat.com \ --cc=rientjes@google.com \ /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: linkBe 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.