Nice 19 process still gets some CPU

Given how much I've read here about schedulers, I should probably be able to answer this question myself, but I just thought I might talk to the experts.

I'm running SETI@Home, and it has a nice value of 19. Everything else, for the most part, is at zero.

I'm running kernel gentoo-dev-sources-2.6.7-r6 (I believe).

When I'm not running SETI@Home, compiler threads (emerge of a package, kernel compile, etc.) get 100% CPU. When I AM running SETI@Home, SETI@Home still manages to get between 5% and 10% CPU.

I would expect that nice 0 processes should get SO MUCH more than nice 19 processes that the nice 19 process would practically starve (and in the case of a nice 19 process, I think starvation by nice 0 processes is just fine), but it looks like it's not starving.

Why is that?

Thanks.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Timothy Miller wrote:

| Given how much I've read here about schedulers, I should probably be
| able to answer this question myself, but I just thought I might talk to
| the experts.
|
| I'm running SETI@Home, and it has a nice value of 19.  Everything else,
| for the most part, is at zero.
|
| I'm running kernel gentoo-dev-sources-2.6.7-r6 (I believe).
|
| When I'm not running SETI@Home, compiler threads (emerge of a package,
| kernel compile, etc.) get 100% CPU.  When I AM running SETI@Home,
| SETI@Home still manages to get between 5% and 10% CPU.
|
| I would expect that nice 0 processes should get SO MUCH more than nice
| 19 processes that the nice 19 process would practically starve (and in
| the case of a nice 19 process, I think starvation by nice 0 processes is
| just fine), but it looks like it's not starving.
|
| Why is that?

It definitely should _not_ starve. That is the unixy way of doing things. Everything must go forward. Around 5% cpu for nice 19 sounds just right. If you want scheduling only when there's spare cpu cycles you need a sched batch(idle) implementation.

Con
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFA4DN2ZUg7+tp6mRURAul+AJ4v3CXwD/XZtjarmTCo7ntISETHdACfYIWT MdJ8lxP3+Z/A4tTipWSDlgA=
=MeGN
-----END PGP SIGNATURE-----

Well, since I can't rewrite the app, I can't make it sched batch. Nice values are an easy thing to get at for anything that's running.

Besides, comparing nice 0 to nice 19, I'd expect something more like a 100:1 ratio or worse. (That is, I don't expect nice to be linear.)

Maybe this is just me, but when I set a process to the worst possible priority (nice 19), I expect it only to run when nothing else needs the CPU.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Timothy Miller wrote:

|
|
| Con Kolivas wrote:
|
|>
|> It definitely should _not_ starve. That is the unixy way of doing
|> things. Everything must go forward. Around 5% cpu for nice 19 sounds
|> just right. If you want scheduling only when there's spare cpu cycles
|> you need a sched batch(idle) implementation.
|>
|>
|
| Well, since I can't rewrite the app, I can't make it sched batch.  Nice
| values are an easy thing to get at for anything that's running.
|
| Besides, comparing nice 0 to nice 19, I'd expect something more like a
| 100:1 ratio or worse.  (That is, I don't expect nice to be linear.)
|
| Maybe this is just me, but when I set a process to the worst possible
| priority (nice 19), I expect it only to run when nothing else needs the
| CPU.

Sched batch is a kernel modification, and a simple wrapper will allow you to run _any_ program as sched batch without modifying it's source.

The design has had that ratio of 20:1 for a very long time so now is not the time to suddenly decide it should be different. However if you want to make it 100:1 for your machine feel free to edit kernel/sched.c and change
#define MIN_TIMESLICE ( 10 * HZ / 1000)
to
#define MIN_TIMESLICE ( 1 * HZ / 1000)

That will give you more what you're looking for.

Con
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFA4DhDZUg7+tp6mRURAi0uAJ9vQ6b7XMGoiHP9lZxgj7yvQNwAsgCfX0u9 SZqOk5k2bm8yRBQKLY2jXsw=
=sqg0
-----END PGP SIGNATURE-----

And if HZ is 100, you have gone from 1 to 0 which probably means you haven't done anything. It seems that if a process is computable, it will always get the CPU at least for one tick.

The original poster wants it to not get the CPU if there is anything else that is computable. Since the scheduler looks at each task in turn, I don't think that ever happens with the either SCHED_FIFO or SCHED_RR. Maybe he can change the policy to SCHED_OTHER and see if that works.

The granularity of -19 to +19 is not really very good for fine process control in Unix..

Cheers,
Dick Johnson
Penguin : Linux version 2.4.26 on an i686 machine (5570.56 BogoMips).
Note 96.31% of all statistics are fiction.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Richard B. Johnson wrote:

| On Tue, 29 Jun 2004, Con Kolivas wrote:
|
|
|>-----BEGIN PGP SIGNED MESSAGE-----
|>Hash: SHA1
|>
|>Timothy Miller wrote:
|>|
|>|
|>| Con Kolivas wrote:
|>|
|>|>
|>|> It definitely should _not_ starve. That is the unixy way of doing
|>|> things. Everything must go forward. Around 5% cpu for nice 19 sounds
|>|> just right. If you want scheduling only when there's spare cpu cycles
|>|> you need a sched batch(idle) implementation.
|>|>
|>|>
|>|
|>| Well, since I can't rewrite the app, I can't make it sched batch.  Nice
|>| values are an easy thing to get at for anything that's running.
|>|
|>| Besides, comparing nice 0 to nice 19, I'd expect something more like a
|>| 100:1 ratio or worse.  (That is, I don't expect nice to be linear.)
|>|
|>| Maybe this is just me, but when I set a process to the worst possible
|>| priority (nice 19), I expect it only to run when nothing else needs the
|>| CPU.
|>
|>
|>Sched batch is a kernel modification, and a simple wrapper will allow
|>you  to run _any_ program as sched batch without modifying it's source.
|>
|>The design has had that ratio of 20:1 for a very long time so now is not
|>the time to suddenly decide it should be different. However if you want
|>to make it 100:1 for your machine feel free to edit kernel/sched.c
|>and change
|>#define MIN_TIMESLICE		( 10 * HZ / 1000)
|>to
|>#define MIN_TIMESLICE		( 1 * HZ / 1000)
|>
|>That will give you more what you're looking for.
|>
|>Con
|
|
|
| And if HZ is 100, you have gone from 1 to 0 which probably
| means you haven't done anything. It seems that if a process
| is computable, it will always get the CPU at least for one
| tick.

Well that aint half obvious. He implied he was running a vanilla kernel which does not support setting Hz.

|
| The original poster wants it to not get the CPU if there is
| anything else that is computable. Since the scheduler looks
| at each task in turn, I don't think that ever happens with
| the either SCHED_FIFO or SCHED_RR. Maybe he can change the
| policy to SCHED_OTHER and see if that works.

Errr sched other is sched normal by the way. What he's looking for is sched batch.

|
| The granularity of -19 to +19 is not really very good for
| fine process control in Unix..

You're kidding. How often do you need that fine control? I feel a sched batch implementation is required... which is why I made one. I've not bothered to even begin to try pushing it upstream because it is not securely enough constructed to prevent DoS when a semaphore is held. I don't think anyone will fully tackle this problem any time soon.

Con
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFA4D2UZUg7+tp6mRURAstVAJ9L0i1A94cPhIZvgMK5jfIE4GC5qgCdGRc6 F9FlyerkoUD9etNA6qfK1cE=
=XMkX
-----END PGP SIGNATURE-----

Cool!!!

As a start, I was palnning to ask such a question on LKML for a long time, but somehow I always forget. Also running SETI@Home on a few Gentoo boxen, but with stock kernels (now 2.6.7). Now that I started reading the first e-mail I thought something like "Oh, so I _did_ send that mail?!?" :-)

I think I will check the suggested MIN_TIMESLICE thing on next recompile, but it started me thinking...
Will it be very difficult to have /proc/sched/min_timeslice or something, instead of the above compile-time define?
That will be really good thing for the our cases and souldn't (or am I overseeing something) pose problems for "normal" usage. RFE!

BTW, the mentioned "sched batch kernel modification" is something else, right? Google wasn't very usefull for "sched batch"...

Can you post any concrete pointers/patches for the sched batch modification?

Kalin.

||///_ o  *****************************
||//'_/>     WWW: http://ThinRope.net/
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kalin KOZHUHAROV wrote:

| Con Kolivas wrote:
|
|> Timothy Miller wrote:
|> |
|> | Con Kolivas wrote:
|> |
|> |>
|> |> It definitely should _not_ starve. That is the unixy way of doing
|> |> things. Everything must go forward. Around 5% cpu for nice 19 sounds
|> |> just right. If you want scheduling only when there's spare cpu cycles
|> |> you need a sched batch(idle) implementation.
|> |>
|> |
|> | Well, since I can't rewrite the app, I can't make it sched batch.  Nice
|> | values are an easy thing to get at for anything that's running.
|> |
|> | Besides, comparing nice 0 to nice 19, I'd expect something more like a
|> | 100:1 ratio or worse.  (That is, I don't expect nice to be linear.)
|> |
|> | Maybe this is just me, but when I set a process to the worst possible
|> | priority (nice 19), I expect it only to run when nothing else needs the
|> | CPU.
|>
|>
|> Sched batch is a kernel modification, and a simple wrapper will allow
|> you  to run _any_ program as sched batch without modifying it's source.
|>
|> The design has had that ratio of 20:1 for a very long time so now is not
|> the time to suddenly decide it should be different. However if you want
|> to make it 100:1 for your machine feel free to edit kernel/sched.c
|> and change
|> #define MIN_TIMESLICE        ( 10 * HZ / 1000)
|> to
|> #define MIN_TIMESLICE        ( 1 * HZ / 1000)
|>
|> That will give you more what you're looking for.
|
|
| Cool!!!

Be aware that it only works if you have not changed the Hz from the default of 1000.

|
| As a start, I was palnning to ask such a question on LKML for a long
| time, but
| somehow I always forget. Also running SETI@Home on a few Gentoo boxen,
| but with
| stock kernels (now 2.6.7). Now that I started reading the first e-mail I
| thought
| something like "Oh, so I _did_ send that mail?!?" :-)
|
| I think I will check the suggested MIN_TIMESLICE thing on next
| recompile, but
| it started me thinking...
| Will it be very difficult to have /proc/sched/min_timeslice or
| something, instead of
| the above compile-time define?
| That will be really good thing for the our cases and souldn't (or am I
| overseeing
| something) pose problems for "normal" usage. RFE!

There is such a thing available if you check the archives. The only problem with changing the min timeslice is that once you get below 10ms you get significant cache trashing and wasted cpu cycles.

|
| BTW, the mentioned "sched batch kernel modification" is something else,
| right?
| Google wasn't very usefull for "sched batch"...

My staircase scheduler in 2.6.7-ck3 supports sched batch.
http://kernel.kolivas.org

|
| Can you post any concrete pointers/patches for the sched batch
| modification?
|
| Kalin.
|

Con
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFA4D53ZUg7+tp6mRURAq1/AJ9BydANnAGCUWdRwwo9pJZj6SETdQCeLS0x LFKhpZsxOHJCysLpUzqRrjU=
=MO5c
-----END PGP SIGNATURE-----

Sure you can. You can set the scheduler policy on any process in the system, while its running.

int sched_setscheduler(pid_t pid, int policy, const struct sched_param *p);

Takes about two minutes to write an equivalent to "nice" to set scheduler policies and priorities.

Chris

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoting Chris Friesen <[email protected]>:

Sounds cool. I was searching this syscall for a long time, now. :) But batch scheduling is available in -ck only, so this works only with -ck kernels. Correct?

- --
Regards Michael Buesch [ http://www.tuxsoft.de.vu ]

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA4EYfFGK1OIvVOP4RAogAAKCQ8oYHshIKPXYNAVptHh1QJRRfywCfX8Cg GxzK64XtYdtnJLReOMrzR3o=
=ithN
-----END PGP SIGNATURE-----

Yep.

Chris

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael Buesch wrote:

| Quoting Chris Friesen <[email protected]>:
|
|>>Timothy Miller wrote:
|>>
|>>>
|>>>Con Kolivas wrote:
|>>>
|>>> >
|>>> > It definitely should _not_ starve. That is the unixy way of doing
|>>> > things. Everything must go forward. Around 5% cpu for nice 19 sounds
|>>> > just right. If you want scheduling only when there's spare cpu cycles
|>>> > you need a sched batch(idle) implementation.
|>>> >
|>>> >
|>>>
|>>>Well, since I can't rewrite the app, I can't make it sched batch.  Nice
|>>>values are an easy thing to get at for anything that's running.
|>>
|>>Sure you can.  You can set the scheduler policy on any process in the
system,
|>>while its running.
|>>
|>>int sched_setscheduler(pid_t pid, int policy, const struct

sched_param *p);
|>>
|>>Takes about two minutes to write an equivalent to "nice" to set scheduler

|>>policies and priorities.
|
|
| Sounds cool. I was searching this syscall for a long time, now. :)
| But batch scheduling is available in -ck only, so this works only
| with -ck kernels. Correct?

Easy to do with the wrapper too:
schedtool -B $pid

or if it's not running yet:
schedtool -B -e $application

schedtool is here:
http://freshmeat.net/projects/schedtool/?topic_id=136

Con
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFA4IpbZUg7+tp6mRURAkx/AJ9fRpPkp5itK9cgPjiG9dArVe0emwCfe8KV 144Ax1BFUBYy7OskVVNU7Ys=
=Hm9h
-----END PGP SIGNATURE-----

If you wish to control the "severity" of nice you should try the "pb" mode of the scheduler evaluation patch:

<http://prdownloads.sourceforge.net/cpuse/patch-2.6.7-spa_hydra_FULL-v1.2?download>

The "severity" of nice will vary with the ratio of the promotion interval (/proc/sys/kernel/cpusched/promotion_interval in milliseconds) to the time slice (/proc/sys/kernel/cpusched/time_slice also in milliseconds). To experiment with these settings you can use two CPU bound processes with different nice values and use top to see how much changing the promotion interval to time slice ratio effects their CPU usage rates.

There's a primitive GUI for setting these parameters' values at:

<http://prdownloads.sourceforge.net/cpuse/gcpuctl_hydra-1.0.tar.gz?download>

Peter

Peter Williams                                   [email protected]

"Learning, n. The kind of ignorance distinguishing the studious."
 -- Ambrose Bierce

when i was running seti@home (more than 10k WU, 7y), i was using a a
home-maid script that controled the seti process. when load > <value> i was stopping seti (SIGSTOP) then, when load <value>, i was restarting it (SIGCONT). i was using a kind of fuzzy logic to prevent from too frequent switchs and i was polling the 3 loads to make a efficient decision. that way, i was able to get 100% of my cpu when it was needed : while playing quake or comipiling a big stuff.

Benoît Dejean
JID: [email protected]
http://gdesklets.gnomedesktop.org
http://www.paulla.asso.fr

Hi Con, Timothy,

5% seems a bit much for many people and they'd rather like to see 0%, but given that we need to make progress, it could be tuned to ~1%.

Note that whenever the compiler will need to wait for the disk (page in binary code, swapping, reading headers), the nice process will get to run, so in practice the compiler does lose less than it seems at first sight. If the nice process weren't, you'd see a certain percentage of I/O wait ...

Regards,

Kurt Garloff  <[email protected]>                            Cologne, DE 
SUSE LINUX AG / Novell, Nuernberg, DE               Director SUSE Labs