[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <48AACF41.5090905@linux.vnet.ibm.com>
Date: Tue, 19 Aug 2008 19:18:49 +0530
From: Balbir Singh <balbir@...ux.vnet.ibm.com>
To: Hirokazu Takahashi <taka@...inux.co.jp>
CC: ryov@...inux.co.jp, kamezawa.hiroyu@...fujitsu.com,
xen-devel@...ts.xensource.com,
containers@...ts.linux-foundation.org,
linux-kernel@...r.kernel.org,
virtualization@...ts.linux-foundation.org, dm-devel@...hat.com,
agk@...rceware.org, xemul@...nvz.org, fernando@....ntt.co.jp
Subject: Re: [PATCH 4/7] bio-cgroup: Split the cgroup memory subsystem into
two parts
Hirokazu Takahashi wrote:
> Hi,
>
>>>> I'm now writing remove-lock-page-cgroup patches. it works well.
>>>> please wait for a while...
>>> I'm looking forward to those patches.
>>>
>>> By the way, I'm glad if memory-cgroup has a feature which can make a
>>> page_cgroup move between cgroups with small overhead. It makes
>>> bio-cgroup improve the accuracy of tracking down pages.
>> Page movement can be a very expensive operation and is proportional to the size
>> of the control group. I think movement should be an optional feature, if we ever
>> add it.
>
> Yes, we should avoid moving pages as far as it is balanced fairly well
> between groups.
>
> But I want to move pages between bio-cgoups in case it started charging
> quite a few I/O requests to a wrong bio-cgroup. I think it will be okay
> if pages moves between bio-cgroups, but they don't need to move between
> memory cgroups. I know the latter is really heavy and the effect seems
> to be so limited.
I was under the impression that you wanted memory-cgroup to provide the page
movement feature. That is not on the TODO list for us now.
--
Balbir
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists