All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Galbraith <umgwanakikbuti@gmail.com>
To: paul.szabo@sydney.edu.au, Peter Zijlstra <peterz@infradead.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: CFS scheduler unfairly prefers pinned tasks
Date: Thu, 08 Oct 2015 10:19:50 +0200	[thread overview]
Message-ID: <1444292390.3389.100.camel@gmail.com> (raw)
In-Reply-To: <1444099557.2832.48.camel@gmail.com>

On Tue, 2015-10-06 at 04:45 +0200, Mike Galbraith wrote:
> On Tue, 2015-10-06 at 08:48 +1100, paul.szabo@sydney.edu.au wrote:
> > The Linux CFS scheduler prefers pinned tasks and unfairly
> > gives more CPU time to tasks that have set CPU affinity.
> > This effect is observed with or without CGROUP controls.
> > 
> > To demonstrate: on an otherwise idle machine, as some user
> > run several processes pinned to each CPU, one for each CPU
> > (as many as CPUs present in the system) e.g. for a quad-core
> > non-HyperThreaded machine:
> > 
> >   taskset -c 0 perl -e 'while(1){1}' &
> >   taskset -c 1 perl -e 'while(1){1}' &
> >   taskset -c 2 perl -e 'while(1){1}' &
> >   taskset -c 3 perl -e 'while(1){1}' &
> > 
> > and (as that same or some other user) run some without
> > pinning:
> > 
> >   perl -e 'while(1){1}' &
> >   perl -e 'while(1){1}' &
> > 
> > and use e.g.   top   to observe that the pinned processes get
> > more CPU time than "fair".

I see a fairness issue with pinned tasks and group scheduling, but one
opposite to your complaint.
 
Two task groups, one with 8 hogs (oink), one with 1 (pert), all are pinned.
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ P COMMAND
 3269 root      20   0    4060    724    648 R 100.0 0.004   1:00.02 1 oink
 3270 root      20   0    4060    652    576 R 100.0 0.004   0:59.84 2 oink
 3271 root      20   0    4060    692    616 R 100.0 0.004   0:59.95 3 oink
 3274 root      20   0    4060    608    532 R 100.0 0.004   1:00.01 6 oink
 3273 root      20   0    4060    728    652 R 99.90 0.005   0:59.98 5 oink
 3272 root      20   0    4060    644    568 R 99.51 0.004   0:59.80 4 oink
 3268 root      20   0    4060    612    536 R 99.41 0.004   0:59.67 0 oink
 3279 root      20   0    8312    804    708 R 88.83 0.005   0:53.06 7 pert
 3275 root      20   0    4060    656    580 R 11.07 0.004   0:06.98 7 oink
.
That group share math would make a huge compute group with progress
checkpoints sharing an SGI monster with one other hog amusing to watch.
  
	-Mike


  parent reply	other threads:[~2015-10-08  8:19 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-05 21:48 CFS scheduler unfairly prefers pinned tasks paul.szabo
2015-10-06  2:45 ` Mike Galbraith
2015-10-06 10:06   ` paul.szabo
2015-10-06 12:17     ` Mike Galbraith
2015-10-06 20:44       ` paul.szabo
2015-10-07  1:28         ` Mike Galbraith
2015-10-08  8:19   ` Mike Galbraith [this message]
2015-10-08 10:54     ` paul.szabo
2015-10-08 11:19       ` Peter Zijlstra
2015-10-10 13:22         ` [patch] sched: disable task group re-weighting on the desktop Mike Galbraith
2015-10-10 14:03           ` kbuild test robot
2015-10-10 14:41             ` Mike Galbraith
2015-10-10 17:01           ` Peter Zijlstra
2015-10-10 17:13             ` Peter Zijlstra
2015-10-11  2:25             ` Mike Galbraith
2015-10-11 17:42               ` 4.3 group scheduling regression Mike Galbraith
2015-10-12  7:23                 ` Peter Zijlstra
2015-10-12  7:44                   ` Mike Galbraith
2015-10-12  8:04                     ` Peter Zijlstra
2015-10-12  0:53                       ` Yuyang Du
2015-10-12  9:12                         ` Peter Zijlstra
2015-10-12  2:12                           ` Yuyang Du
2015-10-12 10:23                             ` Mike Galbraith
2015-10-12 19:55                               ` Yuyang Du
2015-10-13  4:08                                 ` Mike Galbraith
2015-10-12 20:42                                   ` Yuyang Du
2015-10-13  8:06                                 ` Peter Zijlstra
2015-10-13  0:35                                   ` Yuyang Du
2015-10-13  8:10                                   ` Peter Zijlstra
2015-10-13  0:37                                     ` Yuyang Du
2015-10-12 11:47                             ` Peter Zijlstra
2015-10-12 19:32                               ` Yuyang Du
2015-10-13  8:07                                 ` Peter Zijlstra
2015-10-13  2:22                               ` Mike Galbraith
2015-10-12  8:48                       ` Mike Galbraith
2015-10-10 20:14           ` [patch] sched: disable task group re-weighting on the desktop paul.szabo
2015-10-11  2:38             ` Mike Galbraith
2015-10-11  9:25               ` paul.szabo
2015-10-11 12:49                 ` Mike Galbraith
2015-10-11 19:46           ` paul.szabo
2015-10-12  1:59             ` Mike Galbraith
2015-10-08 14:25       ` CFS scheduler unfairly prefers pinned tasks Mike Galbraith
2015-10-08 21:55         ` paul.szabo
2015-10-09  1:56           ` Mike Galbraith
2015-10-09  2:40           ` Mike Galbraith
2015-10-11  9:43             ` paul.szabo
2015-10-10  3:59     ` Wanpeng Li
2015-10-10  7:58       ` Wanpeng Li
  -- strict thread matches above, loose matches on Subject: below --
2015-10-11 20:59 paul.szabo

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=1444292390.3389.100.camel@gmail.com \
    --to=umgwanakikbuti@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paul.szabo@sydney.edu.au \
    --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 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.