From: Dhaval Giani <dhaval.giani@gmail.com>
To: Marat Khalili <mkh@rqc.ru>, Peter Zijlstra <peterz@infradead.org>,
Mike Galbraith <efault@gmx.de>,
LKML <linux-kernel@vger.kernel.org>
Cc: cgroups@vger.kernel.org
Subject: Re: cgroups and nice
Date: Mon, 28 Nov 2016 16:13:09 -0500 [thread overview]
Message-ID: <CAPhKKr8FWR6sfJNp62Q6bDxR5dAYr5uLf1HqfcVNWpNGYTFoVQ@mail.gmail.com> (raw)
In-Reply-To: <8e909b7a-ad0f-431c-4981-3cafe2690da1@rqc.ru>
[Resending because gmail doesn't understand when to go plaintext :-) ]
[Added a few other folks who might have something to say about it]
On Fri, Nov 25, 2016 at 9:34 AM, Marat Khalili <mkh@rqc.ru> wrote:
> I have a question as a cgroup cpu limits user: how does it interact with
> nice? Documentation creates the impression that, as long as number of
> processes demanding the cpu time exceeds number of available cores, time
> allocated will be proportional to configured cpu.shares. However, in
> practice I observe that group with niced processes significantly under
> perform.
>
> For example, suppose on a 6-core box /cgroup/cpu/group1/cpu.shares is 400,
> and /cgroup/cpu/group2/cpu.shares is 200.
> 1) If I run `stress -c 6` in both groups, I should see approximately 400% of
> cpu time in group1 and 200% in group2 in top output, regardless of their
> relative nice value.
> 2) If I run `nice -n 19 stress -c 1` in cgroup1 and `stress -c 24` in
> group2, I should see at least 100% of cpu time in group1.
>
> What I see is significantly less cpu time in group1 if group1 processes
> happen to have greater nice value, and especially if group2 have greater
> number of processes involved: cpu load of group1 in example 2 can be as low
> as 20%. It may create tensions among users in my case; how can this be
> avoided except by renicing all processes to the same value?
>
>> $ uname -a
>> Linux redacted 2.6.32-642.11.1.el6.x86_64 #1 SMP Fri Nov 18 19:25:05 UTC
>> 2016 x86_64 x86_64 x86_64 GNU/Linux
>
This is an old version of the kernel. Do you see the same behavior on
a newer version of the kernel? (4.8 is the latest stable kernel)
>
>> $ lsb_release -a
>> LSB Version:
>> :base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch
>> Distributor ID: CentOS
>> Description: CentOS release 6.8 (Final)
>> Release: 6.8
>> Codename: Final
>
>
> (My apologies if I'm posting to incorrect list.)
>
> --
>
> With Best Regards,
> Marat Khalili
> --
Thanks,
Dhaval
next parent reply other threads:[~2016-11-28 21:13 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <8e909b7a-ad0f-431c-4981-3cafe2690da1@rqc.ru>
2016-11-28 21:13 ` Dhaval Giani [this message]
2016-11-30 9:51 ` cgroups and nice Marat Khalili
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=CAPhKKr8FWR6sfJNp62Q6bDxR5dAYr5uLf1HqfcVNWpNGYTFoVQ@mail.gmail.com \
--to=dhaval.giani@gmail.com \
--cc=cgroups@vger.kernel.org \
--cc=efault@gmx.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mkh@rqc.ru \
--cc=peterz@infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).