Re: Re: -mm merge plans for 2.6.26 (memcgroup)

[kamezawa . hiroyu]

>On Mon, 21 Apr 2008, Andi Kleen wrote:
>> Hugh Dickins wrote:
>> > On Mon, 21 Apr 2008, Balbir Singh wrote:
>> > I've added Andi to the Cc's, I don't want to sneak away something
>> > he's expecting there.  If 2.6.25 had gone out with a convention that
>> > controller infrastructure gets compiled in, but has then to be enabled
>> > at boottime or runtime, okay; 
>> 
>> That is what I have been expecting yes.
>> 
>> If later the slow down is fixed it can be also enabled by default too.
>
>It is disabled by default, in the config; and Paul/Balbir already
>provided the cgroup_disable=memory bootoption to override that.
>
>Is it wise to add an additional hurdle now that 2.6.25 has gone out?
>Is it wise to switch it around in future?  Seems a source of confusion
>to me (I already wasted time testing the same things twice in -mm
>because of this).
>
>I guess Andrew needs to make an executive decision!
>Whichever way round, we ought to clarify the config helptext.
>
Hmm, IMHO, following is a  way.
1. set default config=y and change the config helptext's to
   "This feature is disabled at boot time as default..."
2. add a switch to enable memory conroller after boot. (if possible)

Adding "if"s to page-fault path is too bad ?

About overhead, I think we can reduce it to some extent but amounts of
codes to be added will increase overhead again. Most of features 
is not implemented now (I think).

I'm now preparing performance improvement patches on 2.6.25 and will be
able to show some numbers in the current kernel.

Thanks,
-Kame



 




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