[Lxc-users] cgroup behavior

[Serge Hallyn]

Quoting David Parks (davidparks21 at yahoo.com):
> Speaking of cgroup behavior, you reminded me, I have an open question that
> nobody managed to pick up on unix.stackexchange.com regarding blkio not
> working as expected, maybe you can take a stab at it...
> 
>  
> 
> I've got 2 LXC containers with these cgroup settings:
> 
>  
> 
> lxc.cgroup.blkio.weight = 200
> 
> lxc.cgroup.cpu.shares = 200
> 
>  
> 
>   and another container with:
> 
> lxc.cgroup.blkio.weight = 800
> 
> lxc.cgroup.cpu.shares = 800
> 
>  
> 
> I have verified in /sys/fs/cgroup/blkio/lxc/<container-name>/blkio.weight is
> indeed set to 200 on the host OS.
> 
>  
> 
> I have verified that cpu.shares are indeed split up, 80% to container 1 and
> 20% to container 2.
> 
>  
> 
> But when I run this command in both containers:
> 
>  
> 
> # write a 10GB file to disk
> 
> dd bs=1M count=10000 if=/dev/zero of=1test conv=fdatasync
> 
>  
> 
> I ran a similar test on reads.:
> 
>  
> 
> davidparks21 at test-cgroups1:/tmp$ time sh -c "dd if=1test of=/dev/null bs=1M"
> 
> 10000+0 records in
> 
> 10000+0 records out
> 
> 10485760000 bytes (10 GB) copied, 37.9176 s, 277 MB/s
> 
>  
> 
> real    0m37.939s
> 
> user    0m0.004s
> 
> sys     0m24.306s
> 
>  
> 
> The IO speeds see in iotop on the host OS are virtually the same between the
> two containers.
> 
>  
> 
> I expected to see container 2 command 80% of the IO access in this case.

Hm, that indeed doesn't sound right.  Might be worth bringing this up
on the cgroup mailing list.  However, you also might check the
Documentation/cgorups/blkio-controller.txt file and make sure you
have the right scheduler in your kernel.   Frankly I find that file
confusing.

Note that cgroup hierarchy support is still being cleaned up right now
(thanks mainly to Tejun) and blkio looks to be one of the controllers
which didn't handle hierarchies correctly.

Oh, at the end of that file I see

> - Currently only sync IO queues are support. All the buffered writes are
> still system wide and not per group. Hence we will not see service
> differentiation between buffered writes between groups.

which might mean that dd (presumably not being async) is not per group?

I'd ask on cgroup list.

-serge