From: Dhaval Giani <dhaval-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
To: Mukesh G <mukgbv-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org,
Bharata B Rao
<bharata-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
Subject: Re: Understanding CPU containers
Date: Fri, 11 Sep 2009 16:51:25 +0530 [thread overview]
Message-ID: <20090911112124.GG4474@linux.vnet.ibm.com> (raw)
In-Reply-To: <c7704c490909090330m494bc910n170f04c09cdeeeea-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
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
prev parent reply other threads:[~2009-09-11 11:21 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-09 10:30 Understanding CPU containers Mukesh G
[not found] ` <c7704c490909090330m494bc910n170f04c09cdeeeea-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-09-09 14:03 ` Serge E. Hallyn
2009-09-11 11:21 ` Dhaval Giani [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090911112124.GG4474@linux.vnet.ibm.com \
--to=dhaval-23vcf4htsmix0ybbhkvfkdbpr1lh4cv8@public.gmane.org \
--cc=bharata-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org \
--cc=containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org \
--cc=mukgbv-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.