[dm-devel] Re: dm-ioband + bio-cgroup benchmarks

[Balbir Singh]

KAMEZAWA Hiroyuki wrote:
> On Fri, 19 Sep 2008 12:34:05 +0900 (JST)
> Hirokazu Takahashi <taka at valinux.co.jp> wrote:
> 
>> I've decided to get Ryo to post the accurate dirty-page tracking patch
>> for bio-cgroup, which isn't perfect yet though. The memory controller
>> never wants to support this tracking because migrating a page between
>> memory cgroups is really heavy.
>>
>> I also thought enhancing the memory controller would be good enough,
>> but a lot of people said they wanted to control memory resource and
>> block I/O resource separately.
>> So you can create several bio-cgroup in one memory-cgroup,
>> or you can use bio-cgroup without memory-cgroup.
>>
>> I also have a plan to implement more acurate tracking mechanism
>> on bio-cgroup after the memory cgroup team re-implement the infrastructure,
>> which won't be supported by memory-cgroup.
>> When a process are moved into another memory cgroup,
>> the pages belonging to the process don't move to the new cgroup
>> because migrating pages is so heavy. It's hard to find the pages
>> from the process and migrating pages may cause some memory pressure.
>> I'll implement this feature only on bio-cgroup with minimum overhead
>>
> I really would like to move page_cgroup to new cgroup when the process moves...
> But it's just in my plan and I'm not sure I can do it or not.
> 

Kamezawa-San, I am not dead against it, but I would provide a knob/control point
for system administrator to decide if movement is important for applications,
then let them do so (like force_empty).

> Anyway what's next for me is
>  1. fix current discussion to remove page->page_cgroup pointer.
>  2. reduce locks.

Are you planning on reposting these. I've been trying other approaches at my end

1. Use radix tree per-node per-zone
2. Use radix trees only for 32 bit systems
3. Depend on CONFIG_HAVE_MEMORY_PRESENT and build a sparse data structure and
use pre-allocation

I've posted (1) and I'll take a look at your patches as well

>  3. support swap and swap-cache.
> 
> I think algorithm for (1), (2) is now getting smart.
> 

Yes, it is getting better

> Thanks,
> -Kame
> 


-- 
	Balbir