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

[KAMEZAWA Hiroyuki]

On Tue, 02 Sep 2008 15:42:43 +0530
Balbir Singh <balbir@xxxxxxxxxxxxxxxxxx> 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 ;)

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/