Re: Linux scheduler (scheduling) questions vs threads

[Bill Davidsen]

Ingo Molnar wrote:
> * Povolotsky, Alexander <Alexander.Povolotsky@xxxxxxxxxxx> wrote:
>
>
> > Sorry for bothering and annoying everyone on this list again with additional
> > questions ...
> >
> > Let assume there is one (and only one) application (user space ) process
> > running on the Linux 2.6 - with multiple threads within it, created via
> > "clone" (this happens, I presume, for example, if one uses Monta Vista
> > library for porting PSOS to Linux).
> >
> > What scheduling policies those threads (within the same process) will be
> > governed by (if any )?
>
>
> in Linux there's no difference between the scheduling of 'threads' and
> 'processes'. Both are internally a 'task'. If two tasks share the same
> MM (this is possible via the use of clone()) then they are called
> threads. If a task has its own MM (normally created via fork()) then
> it's called a process - but the scheduler doesnt care.
>
> so the normal Linux scheduling policy applies to 'threads' too. Fully
> preemptable, SCHED_NORMAL by default, or SCHED_FIFO/SCHED_RR if you set
> it. The priority (or rt_priority) can be set per-task as well. Newly
> created threads/processes may inherit (or not) the policy of the parent,
> this largely depends on the library implementation.

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. There is a Mandelbrot 
drawing program which allows use of threads, it will do very bad things 
to system performance to have 8 CPU bound threads generating graphics so 
X is doing a lot of work as well. Student claimed it was part of his 
math homework...

--
   -bill davidsen (davidsen@xxxxxxx)
"The secret to procrastination is to put things off until the
 last possible moment - but no longer"  -me
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/