From: Con Kolivas <kernel@kolivas.org>
To: Carlos Carvalho <carlos@fisica.ufpr.br>
Cc: linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
Andrew Morton <akpm@osdl.org>
Subject: Re: problem with nice values and cpu consumption in 2.6.11-5
Date: Wed, 4 May 2005 22:12:24 +1000 [thread overview]
Message-ID: <200505042212.26453.kernel@kolivas.org> (raw)
In-Reply-To: <17015.35256.12650.37887@fisica.ufpr.br>
[-- Attachment #1: Type: text/plain, Size: 1701 bytes --]
On Wed, 4 May 2005 00:24, Carlos Carvalho wrote:
> Look at this cpu usage in a two-processor machine:
>
> 893 user1 39 19 7212 5892 492 R 99.7 1.1 3694:29 mi41
> 1118 user2 25 0 155m 61m 624 R 50.0 12.3 857:54.18 b170-se.x
> 1186 user3 25 0 155m 62m 640 R 50.2 12.3 103:25.22 b170-se.x
>
> The job with nice 19 seems to be using 100% of cpu time while the
> other two nice 0 jobs share a single processor with 50% only. This is
> persistent, not a transient. I did a kill -STOP to the nice 19 job and
> a kill -CONT, and for a while it decreased the cpu usage but later
> returned to the above.
>
> This is with kernel 2.6.11-5 and top 3.2.5. What's the reason for this
> (apparent??) mis-behavior and how can I correct it? This is important
> because the machine is used for number-crunching and users get really
> upset when they don't get the expected share of cpu time...
We currently do not have "nice" aware SMP balancing. The balancing is purely
designed with throughput in mind, and something about the behaviour of the
tasks you are running makes the scheduler design to balance them in this way.
The only way around this is to use affinities to bind tasks to cpus. The only
cross-cpu "nice" awareness we currently have is between hyperthread (SMT)
logical siblings, and not true physical cores.
I've been experimenting with code to make the SMP balancing "nice" aware but
the balancing design in the 2.6 scheduler changes every 3 minutes for some
apparent gain somewhere (it is getting impossible to track these) and there
is no baseline for me to work off, so I have, for the moment, given up on
that idea.
Cheers,
Con
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
prev parent reply other threads:[~2005-05-04 12:12 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-03 14:24 problem with nice values and cpu consumption in 2.6.11-5 Carlos Carvalho
2005-05-04 11:52 ` Kirill Korotaev
2005-05-04 12:12 ` Con Kolivas [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=200505042212.26453.kernel@kolivas.org \
--to=kernel@kolivas.org \
--cc=akpm@osdl.org \
--cc=carlos@fisica.ufpr.br \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
/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