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-----
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.
-----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-----
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.
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-----
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!!!
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-----
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.
Chris
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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?
> Chris
- --
Regards Michael Buesch [ http://www.tuxsoft.de.vu ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFA4EYfFGK1OIvVOP4RAogAAKCQ8oYHshIKPXYNAVptHh1QJRRfywCfX8Cg
GxzK64XtYdtnJLReOMrzR3o=
=ithN
-----END PGP SIGNATURE-----
Michael Buesch wrote:
> 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?
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-----
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?
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
Le lun, 28/06/2004 à 11:14 -0400, Timothy Miller a écrit :
> 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.
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,
On Tue, Jun 29, 2004 at 01:04:22AM +1000, Con Kolivas wrote:
> Timothy wrote:
> | 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.
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