[lkml]   [2008]   [Sep]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC][PATCH] Remove cgroup member from struct page
KAMEZAWA Hiroyuki wrote:
> On Tue, 02 Sep 2008 15:42:43 +0530
> Balbir Singh <> 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.


 \ /
  Last update: 2008-09-02 14:43    [W:0.132 / U:20.128 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site