public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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 --]

      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