linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: vatsa@linux.vnet.ibm.com
Cc: linuxppc-dev@ozlabs.org, "Ingo Molnar" <mingo@elte.hu>,
	"Peter Zijlstra" <a.p.zijlstra@chello.nl>,
	"Michel Dänzer" <michel@tungstengraphics.com>
Subject: Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
Date: Sat, 26 Jan 2008 15:13:54 +1100	[thread overview]
Message-ID: <1201320834.6815.160.camel@pasglop> (raw)
In-Reply-To: <20080126040734.GA21365@linux.vnet.ibm.com>


On Sat, 2008-01-26 at 09:37 +0530, Srivatsa Vaddagiri wrote:
> 
> Ben,
>         I presume you had CONFIG_FAIR_USER_SCHED turned on too?

Yes. It seems to be automatically turned on whenever FAIR_GROUP is
turned on. Considering how bad the behaviour is for a standard desktop
configuration, I'd be tempted to say to change it to default n.

> Also were the
> dd process and the niced processes running under different user ids? If
> so, that is expected behavior, that we divide CPU equally among
> users first and then among the processes within each user.

They were different users and that behaviour seems to be a very stupid
default behaviour for a desktop machine. Take this situation:

 - X running as root
 - User apps running as "user"
 - Background crap (indexing daemons etc...) running as their own user
or nobody

Unless you can get some kind of grouping based on user sessions
including suid binaries, X etc... I think this shouldn't default y in
Kconfig.

Not that it seems that Michel reported far worse behaviour than what I
saw, including pretty hickup'ish X behaviour even without the fair group
scheduler compared to 2.6.23. It might be because he's running X niced
to -1 (I leave X at 0 and let the scheduler deal with it in general)
though.

> When CONFIG_FAIR_GROUP_SCHED (and CONFIG_FAIR_USER_SCHED) is not
> enabled, X will be given higher priority for running on CPU when compared to 
> other niced tasks. When the above options are turned on, X (running
> under root uid) would be given lesser priority to run when compared to other
> niced tasks running user different uids. Hence I expect some drop in
> interactivity-experience with FAIR_GROUP_SCHED on.
> 
> Can you pls let me know if any of these makes a difference:
> 
> 1. Run niced tasks as root. This would bring X and niced tasks in the
> same "scheduler group" domain, which would give X much more CPU power
> when compared to niced tasks.

I'll dbl check. My tests where indeed done with different users.

> 2. Keep the niced tasks running under a non-root uid, but increase root users 
>    cpu share.
>         # echo 8192 > /sys/kernel/uids/0/cpu_share
> 
>    This should bump up root user's priority for running on CPU and also 
>    give a better desktop experience.

Allright, that's something that might need to be set by default by the
kernel ... as it will take some time to have knowledge of those knobs to
percolate to distros. Too bad you can't do the opposite by default for
"nobody" as there's no standard uid for it.

> The group scheduler's SMP-load balance in 2.6.24 is not the best it
> could be. sched-devel has a better load balancer, which I am presuming
> will go into 2.6.25 soon.
> 
> In this case, I suspect that's not the issue.  If X and the niced processes are 
> running under different uids, this (niced processes getting more cpu power) is 
> on expected lines. Will wait for Ben to confirm this. 

I would suggest turning the fair group scheduler to default n in stable
for now.

Cheers,
Ben.

  reply	other threads:[~2008-01-26  4:14 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-18 12:34 ppc32: Weird process scheduling behaviour with 2.6.24-rc Michel Dänzer
2008-01-22 14:56 ` Michel Dänzer
2008-01-23 12:18   ` Michel Dänzer
2008-01-23 12:36     ` Peter Zijlstra
2008-01-23 13:14       ` Michel Dänzer
2008-01-24  8:18         ` Benjamin Herrenschmidt
2008-01-24  8:46       ` Benjamin Herrenschmidt
2008-01-25 10:57         ` Michel Dänzer
2008-01-23 12:42     ` Peter Zijlstra
2008-01-25  6:54       ` Benjamin Herrenschmidt
2008-01-25  7:03         ` Benjamin Herrenschmidt
2008-01-25  7:25           ` Benjamin Herrenschmidt
2008-01-25  8:50             ` Peter Zijlstra
2008-01-26  4:07               ` Srivatsa Vaddagiri
2008-01-26  4:13                 ` Benjamin Herrenschmidt [this message]
2008-01-26  5:07                   ` Srivatsa Vaddagiri
2008-01-26  5:15                     ` Benjamin Herrenschmidt
2008-01-26  9:26                       ` Srivatsa Vaddagiri
2008-01-26  5:07                   ` Srivatsa Vaddagiri
2008-01-27 16:13                     ` Michel Dänzer
2008-01-28  4:25                       ` Benjamin Herrenschmidt
2008-01-28  8:16                         ` Michel Dänzer
2008-01-28  8:50                       ` Peter Zijlstra
2008-01-28  9:14                         ` Michel Dänzer
2008-01-28 12:11                           ` Srivatsa Vaddagiri
2008-01-28 12:32                         ` Ingo Molnar
2008-01-28 12:53                           ` Peter Zijlstra
2008-01-28 12:56                             ` Ingo Molnar
2008-01-29 10:14                               ` Michel Dänzer
2008-01-28 13:11                           ` Srivatsa Vaddagiri
2008-01-25 11:34         ` Michel Dänzer
2008-01-25 15:04           ` Michel Dänzer
2008-01-25 21:10             ` Benjamin Herrenschmidt

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=1201320834.6815.160.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=michel@tungstengraphics.com \
    --cc=mingo@elte.hu \
    --cc=vatsa@linux.vnet.ibm.com \
    /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).