Re: [RFC][PATCH] Remove cgroup member from struct page

[Balbir Singh <balbir@linux.vnet.ibm.com>]

KAMEZAWA Hiroyuki wrote:
> On Tue, 02 Sep 2008 15:42:43 +0530
> Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
>>>>>> Kamezawa-San, I would like to integrate the radix tree patches after review and
>>>>>> some more testing then integrate your patchset on top of it. Do you have any
>>>>>> objections/concerns with the suggested approach?
>>>>>>
>>>>> please show performance number first.
>>>> Yes, that is why said some more testing. I am running lmbench and kernbench on
>>>> it and some other tests, I'll get back with numbers.
>>>>
>>> A test which is not suffer much from I/O is better.
>>> And please don't worry about my patches. I'll reschedule if yours goes first.
>>>
>> Thanks, I'll try and find the right set of tests.
> 
> Maybe it's good time to share my concerns.
> 
> IMHO, the memory resource controller is for dividing memory into groups.
> 
> We have following choices to divide memory into groups, now.
>   - cpuset(+ fake NUMA)
>   - VM (kvm, Xen, etc...)
>   - memory resource controller. (memcg)
> 
> Considering 3 aspects peformance, flexibility, isolation(security).
> My expectaion is
> 
> peroformance   : cpuset > memcg >> VMs
> flexibility    : memcg  > VMs >> cpuset.
> isolation      : VMs >> cpuset >= memcg
> 
> The word 'flexibility' sounds sweet *but* it's just one of aspects.
> If the peformance is cpuset > VMs > memcg, I'll advise users to use VMs.
> 
> I think VMs are getting faster and faster. memcg will be slower when we add new
> 'fancy' feature more. (I think we need some more features.)
> So, I want to keep memcg fast as much as possible at this stage.
> 
> But yes, memory usage overhead of page->page_cgroup, struct page_cgroup is big
> on 32bit arch. I'll say users to use VMs, maybe ;)

I understand your concern and I am not trying to reduce memcg's performance - or
add a fancy feature. I am trying to make memcg more friendly for distros. I see
your point about the overhead. I just got back my results - I see a 4% overhead
with the patches. Let me see if I can rework them for better performance.


-- 
	Balbir