The old vcap-dev mailing list had a number of exchanges around this topic
that you might want to look at.

The basic gist is that linux gives processes that are not associated with a
cgroup a cpu share of 1024. That means that the code that runs the DEA and
all of the linux daemons that make things go will get that share.

When applications are placed on a DEA, the containers they run in are
associated with a cpu share that is proportional to the amount of memory
requested. If you request a lot of memory per app instance, you'll have a
high cpu share; if you request a little memory per app instance, you'll
have a low cpu share.

The cpu share values associated with the container cgroups will never be
allowed to exceed 1024 (to prevent applications from adversely impacting
the DEA processes).

These cpu share values really only start to impact things when there's
competition for the cpu. When that happens, processes in a cgroup that is
associated with higher shares will get more cpu than those with lower
shares.

There is no "limit" to the number of shares - they're treated as relative
values when the scheduler needs to make a choice. The goal is that, given
two processes A and B, if process A has a share weight that is twice that
of process B and both processes are cpu bound, process A will get twice as
many shares of the cpu as process A.

For a more complete understanding, you should read the documentation in the
linux tree for the scheduler.

--
Matthew Sykes
matthew.sykes(a)gmail.com