于 2011年06月21日 22:43, Andrea Arcangeli 写道:
On Tue, Jun 21, 2011 at 12:08:14PM +0800, Cong Wang wrote:
The thing is that we can save ~10K by adding 3 lines of code as this
patch showed, where else in kernel can you save 10K by 3 lines of code?
(except some kfree() cases, of course) So, again, why not have it? ;)
Because you could save it with a more complicated patch that doesn't
cripple down functionality.
Why do you prefer "more complicated" things to simple ones? ;-)
I realized this patch changed the original behavior of "=never",
thus proposed a new "=0" parameter.
But to be honest, "=never" should be renamed to "=disable".
Again if you want to optimize this ~8KB gain, I recommend to add a
param to make the hash size dynamic not to prevent the feature to ever
be enabled again, so by making the code more complex at least it will
also be useful if we want to increase the size hash at boot time (not
only to decrease it).
Not only such things, the more serious thing is that you are
enforcing a policy to users, as long as I enable THP in Kconfig,
I have no way to disable it.
Why are you so sure that every user who has no chance to change
.config likes THP?
And, what can I do if I want to prevent any process from having
a chance to enable THP? Because as long as THP exists in /sys,
any process has the right privilege can change it.
Thanks.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. 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@xxxxxxxxx";> email@xxxxxxxxx </a>