Understanding CPU containers

Understanding CPU containers

[Mukesh G]

Hi,
       I am trying to understand the behavior of CPU containers as I
am unable to explain few things.
- Built the latest kernel 2.6.30.5 and installed on my Intel core2Duo desktop

- Mounted the cpu subsystem using

      - mount -t cgroup -ocpu cgroup /containers/cpu/

- Created 3 sub directories under /containers/cpu

        - 512 for cpu.shares=512

        - 1024 for cpu.shares=1024

        - 2048 for cpu.shares=2048

- Created 3 bash terminals and attached each one to the individual cpu
sub system using the /bin/echo command. This essentially allows any
process created by the shells to be automatically added to the cpu
subsystem to which the shell belongs

- Ran a compute intensive benchmark “openssl speed aes-256-cbc”
benchmark on all the shells at the same time.

- Enclosing the numbers from the run…

    - Observed CPU Utilization : 99.8 , 49.9 , 49.9

Results from the run

The 'numbers' are in 1000s of bytes per second processed.

CPU shares allocation

                            16 bytes                     64 bytes
            256 bytes             1024 bytes             8192 bytes

512                        35459.95k                   43441.75k
          46660.35k            46707.71k              77040.30k

1024                      57448.63k                    44050.54k
          46558.98k            46633.03k              47252.76k

2048                    71186.36k                    87142.02k
        92513.79k            93769.05k              94795.09k

1024 vs 512          1.62                            1.01
            0.99                     0.99                      0.61

2048 vs 1024         1.23                           1.97
           1.98                      2.01                     2

Observations

        - Unless the cpu resources are overcommitted, there is no
value in the allocating shares to the containers.
        - 2048 vs 1024 cpu containers, the scale is 2X, except for 16 bytes
        - 512 vs 1024 cpu containers, there is no difference at all,
except for 16 bytes
        - 512 vs 1024 cpu containers, there is no difference for 8192
bytes as the remaining 2 openssl runs are complete.
        - For CPU bound, there has to be an over commit on the CPUs
otherwise the share allocation does not matter
        - One cannot dynamically assign cpus to the container, by
default, it runs on the no of cores available.

Any pointers are helpful

Thanks

Mukesh

Re: Understanding CPU containers

[Serge E. Hallyn]

Quoting Mukesh G (mukgbv-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org):
> Hi,
>        I am trying to understand the behavior of CPU containers as I
> am unable to explain few things.

...

> Observations
> 
>         - Unless the cpu resources are overcommitted, there is no
> value in the allocating shares to the containers.

Right.  And that observation (which is correct - there is no throttling
if cpu is available) explains the rest.

>         - 2048 vs 1024 cpu containers, the scale is 2X, except for 16 bytes
>         - 512 vs 1024 cpu containers, there is no difference at all,
> except for 16 bytes
>         - 512 vs 1024 cpu containers, there is no difference for 8192
> bytes as the remaining 2 openssl runs are complete.
>         - For CPU bound, there has to be an over commit on the CPUs
> otherwise the share allocation does not matter
>         - One cannot dynamically assign cpus to the container, by
> default, it runs on the no of cores available.
> 
> Any pointers are helpful

Hmm, there isn't a file under Documentation/cgroups?  That should
be fixed...  Meanwhile, the code is mainly in kernel/sched.c.  You
can start with the cgroup subsys definition at
	struct cgroup_subsys cpu_cgroup_subsys = { ...
(around line 10313) and fan out from there.

-serge

Re: Understanding CPU containers

[Dhaval Giani]

On Wed, Sep 09, 2009 at 04:00:27PM +0530, Mukesh G wrote:
> Hi,
>        I am trying to understand the behavior of CPU containers as I
> am unable to explain few things.
> - Built the latest kernel 2.6.30.5 and installed on my Intel core2Duo desktop
> 
> - Mounted the cpu subsystem using
> 
>       - mount -t cgroup -ocpu cgroup /containers/cpu/
> 
> - Created 3 sub directories under /containers/cpu
> 
>         - 512 for cpu.shares=512
> 
>         - 1024 for cpu.shares=1024
> 
>         - 2048 for cpu.shares=2048
> 
> - Created 3 bash terminals and attached each one to the individual cpu
> sub system using the /bin/echo command. This essentially allows any
> process created by the shells to be automatically added to the cpu
> subsystem to which the shell belongs
> 
> - Ran a compute intensive benchmark “openssl speed aes-256-cbc”
> benchmark on all the shells at the same time.
> 
> - Enclosing the numbers from the run…
> 
>     - Observed CPU Utilization : 99.8 , 49.9 , 49.9
> 
> Results from the run
> 
> The 'numbers' are in 1000s of bytes per second processed.
> 
> CPU shares allocation
> 
>                             16 bytes                     64 bytes
>             256 bytes             1024 bytes             8192 bytes
> 
> 512                        35459.95k                   43441.75k
>           46660.35k            46707.71k              77040.30k
> 
> 1024                      57448.63k                    44050.54k
>           46558.98k            46633.03k              47252.76k
> 
> 2048                    71186.36k                    87142.02k
>         92513.79k            93769.05k              94795.09k
> 
> 1024 vs 512          1.62                            1.01
>             0.99                     0.99                      0.61
> 
> 2048 vs 1024         1.23                           1.97
>            1.98                      2.01                     2
> 
> Observations
> 
>         - Unless the cpu resources are overcommitted, there is no
> value in the allocating shares to the containers.
>         - 2048 vs 1024 cpu containers, the scale is 2X, except for 16 bytes
>         - 512 vs 1024 cpu containers, there is no difference at all,
> except for 16 bytes
>         - 512 vs 1024 cpu containers, there is no difference for 8192
> bytes as the remaining 2 openssl runs are complete.

(word wrapping has broken your table for me. I will try to decipher it
and post observations on it later on.)

>         - For CPU bound, there has to be an over commit on the CPUs
> otherwise the share allocation does not matter

Bharata has posted some patches recently at
http://lwn.net/Articles/348578/ which allow one to throttle the amount
of CPU bandwidth available to a cgroup. Any feedback on that will be
great!

>         - One cannot dynamically assign cpus to the container, by
> default, it runs on the no of cores available.

Right. But you can use cpusets to carve out the system if you want to.

-- 
regards,
Dhaval
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers