Linux scheduler (scheduling) questions vs threads
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 11 lines · Chris Siebenmann
You write:
| Ingo Molnar wrote:
[...]
| > so the normal Linux scheduling policy applies to 'threads' too. [...]
[...]
| On a multi-user machine this may result in undesirable behaviour, since | each thread seems to compete for resources and the machine may get VERY | slow if someone deos something anti-social.This is nothing unique to threads; the same problem appears if a
program (or a user) uses a bunch of CPU-eating processes. I imagine that any real solution will have to be per-user 'beancounting' and limits, which have yet to make it into the Linux kernel.
Actually, yes it is. While students can be warned about the results of fork bombing a system, both in terms of what happens to the system and to their access, it's far less obvious that starting a program which does a lot of threads is equally bad behaviour.
The desirability for per-user scheduling is also shown by the student who build a large project with "-j4" as a make option and "-pipe" as a compile option. Yes, it makes the program complete sooner, and it generally is done with no malice.
Hopefully some form of this will appear in the 2.7 kernel, although past discussions in several places have resulted in more heat than light on the topic.
Signature · 3 lines
bill davidsen <[email protected]> CTO TMR Associates, Inc Doing interesting things with small computers since 1979
Quoted 5 lines
Quoted 4 lines · Chris Siebenmann
You write:
| Ingo Molnar wrote:
[...]
| > so the normal Linux scheduling policy applies to
Quoted 13 lines
'threads' too. [...]
Quoted 2 lines
[...]
| On a multi-user machine this may result in undesirablebehaviour, since
Quoted 1 line
| each thread seems to compete for resources and the
machine may get VERY
Quoted 6 lines
| slow if someone deos something anti-social.
This is nothing unique to threads; the same problem appears if a
program (or a user) uses a bunch of CPU-eating processes. I imagine that any real solution will have to be per-user 'beancounting' and limits, which have yet to make it into the Linux kernel.
What about ulimit'ing users ?
bash-2.05$ ulimit -a
core file size (blocks) 0 data seg size (kbytes) unlimited file size (blocks) unlimited max locked memory (kbytes) unlimited max memory size (kbytes) unlimited open files 1024 pipe size (512 bytes) 8 stack size (kbytes) 8192 cpu time (seconds) unlimited max user processes 4087 virtual memory (kbytes) unlimited
Regards,
Paul