effect of sched_set{param|scheduler} on MT-process
Loic Domaigne
After many efforts (I am not a native standardese speaker, so...) , I
think I finally deciphered what's the Single Unix Specification is
telling us regarding the effect of sched_setparam() and
sched_setscheduler() on multi-threaded process.
But I'd like to check if I didn't missed something, or if I got
something wrong! Any comments shall be appreciated.
TIA,
Loic.
| The effect of this function on individual threads is dependent on
| the scheduling contention scope of the threads:
|
| (1) For threads with system scheduling contention scope, these
| functions shall have no effect on their scheduling.
I understand it that way:
Threadings using a 1:1 model (most implementations),
sched_set{scheduler|param} is a NOP.
| (2) For threads with process scheduling contention scope, the
| threads scheduling policy and associated parameters shall not be
| affected. However, the scheduling of these threads with respect to
| threads in other processes may be dependent on the scheduling
| parameters of their process, which are governed using these
| functions.
I read it like:
Threadings using a pure user-space implementation (M:1 model),
sched_set{scheduler|param} is a NOP within that the threads of that
process. However, the scheduling a the process might be changed.
Indeed from a kernel viewpoint, there is only "one thread" to
schedule. So it makes sense to evt. change its scheduling. That
explains the sentence "However, the scheduling of these threads wrt
[...]"
| If an implementation supports a two-level scheduling model in which
| library threads are multiplexed on top of several kernel-scheduled
| entities, then the underlying kernel-scheduled entities for the
| system contention scope threads shall not be affected by these
| functions.
That's the mixed case of the two previous one. KSE competing for
system resources must be invariant to respect case 1).
| The underlying kernel-scheduled entities for the process contention
| scope threads shall have their scheduling policy and associated
| scheduling parameters changed to the values specified in policy and
| param, respectively.
That's what we saw in case 2).
| Kernel-scheduled entities for use by process contention scope
| threads that are created after this call completes shall inherit
| their scheduling policy and associated scheduling parameters from
| the process.
That's a logical consequence. All Process Contention Scope threads
that are mapped to a particular kernel thread, are bound to it. And
thus in particular to its scheduling characteristics. Hence this
inheritance property.
That it makes sense?
Loic Domaigne
Should I take your silence as a confession that my understanding is
correct? Can hardly believe it ;-)
Cheers,
Loic.
> Does it make sense?
Steve Watt
Loic Domaigne <loic...@gmx.net> wrote:
>Common laddies and gentlemen!
>
>Should I take your silence as a confession that my understanding is
>correct? Can hardly believe it ;-)
Pretty close, I'd say.
Caution: I only developed operating systems based on the standard and
talked with one of the standards developers; I wasn't actually on that
committee.
[ ... ]
>> After many efforts (I am not a native standardese speaker, so...) , I
>> think I finally deciphered what's the Single Unix Specification is
>> telling us regarding the effect of sched_setparam() and
>> sched_setscheduler() on multi-threaded process.
I hate to imagine what a native standardese speaker would sound like
in any other language... :)
>> | The effect of this function on individual threads is dependent on
>> | the scheduling contention scope of the threads:
>> |
>> | (1) For threads with system scheduling contention scope, these
>> | functions shall have no effect on their scheduling.
>>
>> I understand it that way:
>> Threadings using a 1:1 model (most implementations),
>> sched_set{scheduler|param} is a NOP.
Yup.
>> | (2) For threads with process scheduling contention scope, the
>> | threads scheduling policy and associated parameters shall not be
>> | affected. However, the scheduling of these threads with respect to
>> | threads in other processes may be dependent on the scheduling
>> | parameters of their process, which are governed using these
>> | functions.
>>
>> I read it like:
>> Threadings using a pure user-space implementation (M:1 model),
>> sched_set{scheduler|param} is a NOP within that the threads of that
>> process. However, the scheduling a the process might be changed.
>> Indeed from a kernel viewpoint, there is only "one thread" to
>> schedule. So it makes sense to evt. change its scheduling. That
>> explains the sentence "However, the scheduling of these threads wrt
>> [...]"
Well, kinda. It is possible (and older Solarises support) to have some
threads in a process be process contention scope (commonly abbreviated
PCS), and some threads in the same process be system contention scope
(commonly abbreviated SCS). In those threads with SCS, sched_set* are
no-ops.
If you have PCS threads, sched_set* will affect the scheduling of all
threads that are PCS in that process, but none of the threads that are
SCS.
Most of the rest of the prose in the standard are corallaries of SCS
vs PCS, potentially all in one process.
--
Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8" / 37N 20' 14.9"
Internet: steve @ Watt.COM Whois: SW32
Free time? There's no such thing. It just comes in varying prices...
Sebastien Decugis
>>>| The effect of this function on individual threads is dependent on
>>>| the scheduling contention scope of the threads:
>>>|
>>>| (1) For threads with system scheduling contention scope, these
>>>| functions shall have no effect on their scheduling.
>>>
>>>I understand it that way:
>>>Threadings using a 1:1 model (most implementations),
>>>sched_set{scheduler|param} is a NOP.
>>>
>>>
>
>Yup.
>
>
contension scope? Couldn't we design a scheduler which knows about
groups of kernel threads representing a process?
>>>| (2) For threads with process scheduling contention scope, the
>>>| threads scheduling policy and associated parameters shall not be
>>>| affected. However, the scheduling of these threads with respect to
>>>| threads in other processes may be dependent on the scheduling
>>>| parameters of their process, which are governed using these
>>>| functions.
>>>
>>>I read it like:
>>>Threadings using a pure user-space implementation (M:1 model),
>>>sched_set{scheduler|param} is a NOP within that the threads of that
>>>process. However, the scheduling a the process might be changed.
>>>Indeed from a kernel viewpoint, there is only "one thread" to
>>>schedule. So it makes sense to evt. change its scheduling. That
>>>explains the sentence "However, the scheduling of these threads wrt
>>>[...]"
>>>
>>>
>
>Well, kinda. It is possible (and older Solarises support) to have some
>threads in a process be process contention scope (commonly abbreviated
>PCS), and some threads in the same process be system contention scope
>(commonly abbreviated SCS). In those threads with SCS, sched_set* are
>no-ops.
>
>
Can't we have the same thing on a 1:1 model?
Thanks...
Loic Domaigne
> I can't understand why a 1:1 model would mean automatically a system
> contension scope? Couldn't we design a scheduler which knows about
> groups of kernel threads representing a process?
Well, 1:1 model means that one thread is mapped to one KSE
(Kernel Schedulable Entity). Kernel only schedules KSE (by definition).
That is, each thread is fighting for the CPU/Memory/whatever_resource
with the other KSEs there (single-threaded processes, or threads
from another process). Isn't it the definition of SCS?
> Couldn't we design a scheduler which knows about groups of kernel
> threads representing a process?
I believe, this is another issue. And actually, UNIX kernel scheduler sees
"a process as a collection of KSEs + other global stuff like opened file
descriptors etc.).
Standard UNIX scheduler shall for instance favorize the scheduling of a
KSE in the same process if the timeslice isn't elapsed.
But it has nothing to do with the implementation model, IMHO.
> >Well, kinda. It is possible (and older Solarises support) to have some
> >threads in a process be process contention scope (commonly abbreviated
> >PCS), and some threads in the same process be system contention scope
> >(commonly abbreviated SCS). In those threads with SCS, sched_set* are
> >no-ops.
> >
> >
> Can't we have the same thing on a 1:1 model?
No, we can't. 1:1 is SCS by definition of the model.
But of course, it is always possible get that using a M:N model
(model used in Solaris up to Solaris 8. Also used by NGPT on Linux, BTW).
Regards,
Loic.
--
Article posté via l'accès Usenet http://www.mes-news.com
Accès par Nnrp ou Web
Kamal R. Prasad
> In article <2pk1o0F...@uni-berlin.de>,
> Loic Domaigne <loic...@gmx.net> wrote:
> >Common laddies and gentlemen!
> >
> >Should I take your silence as a confession that my understanding is
> >correct? Can hardly believe it ;-)
>
> Pretty close, I'd say.
>
> Caution: I only developed operating systems based on the standard and
> talked with one of the standards developers; I wasn't actually on that
> committee.
>
> [ ... ]
>
> >> After many efforts (I am not a native standardese speaker, so...) , I
> >> think I finally deciphered what's the Single Unix Specification is
> >> telling us regarding the effect of sched_setparam() and
> >> sched_setscheduler() on multi-threaded process.
>
> I hate to imagine what a native standardese speaker would sound like
> in any other language... :)
>
> >> | The effect of this function on individual threads is dependent on
> >> | the scheduling contention scope of the threads:
> >> |
> >> | (1) For threads with system scheduling contention scope, these
> >> | functions shall have no effect on their scheduling.
> >>
> >> I understand it that way:
> >> Threadings using a 1:1 model (most implementations),
> >> sched_set{scheduler|param} is a NOP.
>
> Yup.
>
What the std is *PROBABLY* saying [and as you know -Im not one of the
authors] is that whenever possible the process' scheduling
characteristic override sched_set*() operations. You can specify
processes to be real-time/round robin or even load your own scheduler
and have the process handled by it [think solaris has this facility].
The std does not want any of the sched_set*() functions to interfere
with that functioning.
For a case where you have more than 1 thread in process contention
scope, sched_set*() can be used without interfering with the system
wide scheduler's behaviour.
Hope this helps -or is not incorrect.
regards
-kamal
---------------------------
Kamal R. Prasad
UNIX system consultant
http://www.kprasad.org/
Sebastien Decugis
>>I can't understand why a 1:1 model would mean automatically a system
>>contension scope? Couldn't we design a scheduler which knows about
>>groups of kernel threads representing a process?
>>
>>
>
>Well, 1:1 model means that one thread is mapped to one KSE
>(Kernel Schedulable Entity). Kernel only schedules KSE (by definition).
>That is, each thread is fighting for the CPU/Memory/whatever_resource
>with the other KSEs there (single-threaded processes, or threads
>from another process). Isn't it the definition of SCS?
>
>
What is the problem with such a design:
We get 5 KSE: A, B, C, D, E.
A is an independent process (i.e. one thread alone in its process).
B is also an independent process.
C, D, E are three threads belonging to the same process.
Is this correct wrt 1:1 model?
Then, C is set with system scheduling contension scope, and D & E are
process scheduling contension scope.
Assuming every thread has the same priority, a possible scheduling
sequence would be:
A, B, C, D, A, B, C, E, A, B, C, D, A, B, C, E, ...
Otherwise said, we can imagine a top-level concurrency with A, B, C, {D & E}
And a sublevel for the group D & E.
What will be scheduled in this sub-level is either D or E; so we still
respect the KSE and 1:1 model; even if we need the scheduler to know
about conceptual "groups" of KSE.
Where am I mistaking?
Thanks! :)
Steve Watt
Sebastien Decugis <sebastie...@ext.bull.net> wrote:
[ quote origins lost ]
>>>I can't understand why a 1:1 model would mean automatically a system
>>>contension scope? Couldn't we design a scheduler which knows about
>>>groups of kernel threads representing a process?
>>>
>>>
>>
>>Well, 1:1 model means that one thread is mapped to one KSE
>>(Kernel Schedulable Entity). Kernel only schedules KSE (by definition).
>>That is, each thread is fighting for the CPU/Memory/whatever_resource
>>with the other KSEs there (single-threaded processes, or threads
>>from another process). Isn't it the definition of SCS?
>>
>>
>
>We get 5 KSE: A, B, C, D, E.
>A is an independent process (i.e. one thread alone in its process).
>B is also an independent process.
>C, D, E are three threads belonging to the same process.
>
>Is this correct wrt 1:1 model?
Yes.
>Then, C is set with system scheduling contension scope, and D & E are
>process scheduling contension scope.
If the implementation is a strict 1:1 threads model, D and E must be SCS;
such systems don't, support (by definition of "strict 1:1 threads model")
multiple threads sharing one KSE.
>Assuming every thread has the same priority, a possible scheduling
>sequence would be:
>A, B, C, D, A, B, C, E, A, B, C, D, A, B, C, E, ...
Not on a 1:1 system. If D and E are set to PCS, and C is set to SCS all
inside of their process, then that process has *two* KSEs: One for C,
and one for D/E context-switched. This is the standard M:N system.
Hope that helps.
Kamal R. Prasad
> Hello everybody,
>
> After many efforts (I am not a native standardese speaker, so...) , I
> think I finally deciphered what's the Single Unix Specification is
> telling us regarding the effect of sched_setparam() and
> sched_setscheduler() on multi-threaded process.
>
> But I'd like to check if I didn't missed something, or if I got
> something wrong! Any comments shall be appreciated.
>
> TIA,
> Loic.
>
scheduling attributes of the process [as long as it is compiled with
-lpthread].
regards
-kamal
David Schwartz
"Sebastien Decugis" <sebastie...@ext.bull.net> wrote in message
news:4138907e$0$22035$626a...@news.free.fr...
> What is the problem with such a design:
>
> We get 5 KSE: A, B, C, D, E.
> A is an independent process (i.e. one thread alone in its process).
> B is also an independent process.
> C, D, E are three threads belonging to the same process.
>
> Is this correct wrt 1:1 model?
>
> Then, C is set with system scheduling contension scope, and D & E are
> process scheduling contension scope.
>
> Assuming every thread has the same priority, a possible scheduling
> sequence would be:
> A, B, C, D, A, B, C, E, A, B, C, D, A, B, C, E, ...
>
> Otherwise said, we can imagine a top-level concurrency with A, B, C, {D &
> E}
> And a sublevel for the group D & E.
>
> What will be scheduled in this sub-level is either D or E; so we still
> respect the KSE and 1:1 model; even if we need the scheduler to know about
> conceptual "groups" of KSE.
>
> Where am I mistaking?
The problem with such a design is that it gives forking servers a huge
scheduling advantage over multi-threaded servers. Why would you want to do
that?
DS
Sebastien Decugis
> The problem with such a design is that it gives forking servers a huge
>scheduling advantage over multi-threaded servers. Why would you want to do
>that?
>
> DS
>
>
>
>
I have no particular interest in doing it, I was just trying to
understand the "process contension scope" concept. It is true IMHO that
such a concept favorises multi-process applications over multi-thread
ones (scheduling issues). But I can imagine that in a multi users
environment, that can be a wanted behavior: You don't want your app run
slowly because another user is running an application with a lot of
threads...
Thanks,
Sebastien.
--
-------------------------------
Sebastien DECUGIS
NPTL Test & Trace Project
http://nptl.bullopensource.org/
Sebastien Decugis
>>Then, C is set with system scheduling contension scope, and D & E are
>>process scheduling contension scope.
>>
>>
>
>If the implementation is a strict 1:1 threads model, D and E must be SCS;
>such systems don't, support (by definition of "strict 1:1 threads model")
>multiple threads sharing one KSE.
>
>
>
>>Assuming every thread has the same priority, a possible scheduling
>>sequence would be:
>>A, B, C, D, A, B, C, E, A, B, C, D, A, B, C, E, ...
>>
>>
>
>Not on a 1:1 system. If D and E are set to PCS, and C is set to SCS all
>inside of their process, then that process has *two* KSEs: One for C,
>and one for D/E context-switched. This is the standard M:N system.
>
>Hope that helps.
>
>
Yeah that helps thank you. My mistake was that I thought what you call
"D/E context-switched" was equivalent to "D and E are two KSE". It looks
like I don't really understand what is a KSE. I thought it was just an
entity with an associated context in the kernel -- so as it can be
interrupted and another entity is run once its context is restored.
Thanks,
Seb.
David Schwartz
> I have no particular interest in doing it, I was just trying to understand
> the "process contension scope" concept. It is true IMHO that such a
> concept favorises multi-process applications over multi-thread ones
> (scheduling issues). But I can imagine that in a multi users environment,
> that can be a wanted behavior: You don't want your app run slowly because
> another user is running an application with a lot of threads...
No do you want your multi-threaded app to run slowly because another
user is running an application with a lot of processes. Both threads and
processes are ways you can use the CPU, and there's no obvious reason to
treat them differently. Most things that you can do with multiple threads,
you can do with multiple processes, and vice versa.
If you're talking about distributing the CPU 'fairly' between different
users, it's a whole different thing than processes versus threads. You need
to look at what processes and what threads belong to which users.
But it is fair that user X gets four times the CPU of user Y because
he's using 4 processes and the other user is using four threads?
DS
Loic Domaigne
> >Not on a 1:1 system. If D and E are set to PCS, and C is set to SCS all
> >inside of their process, then that process has *two* KSEs: One for C,
> >and one for D/E context-switched. This is the standard M:N system.
> Yeah that helps thank you. My mistake was that I thought what you call
> "D/E context-switched" was equivalent to "D and E are two KSE". It looks
> like I don't really understand what is a KSE. I thought it was just an
> entity with an associated context in the kernel -- so as it can be
> interrupted and another entity is run once its context is restored.
Threads - that is multiple flows of control within a process can be
implemented in user space without help of the kernel. For instance GnuPTH
does that. The kernel is not aware of multiple threads within the process.
That's a N:1 implementation, N threads to 1 KSE.
N:1 implementation have been popular ~15 years ago... But such model as some
well known limitations like blocking syscall, page fault or lack of
parallelism on SMP machines.
And so, almost naturally, people consider "better approach", the 1:1 and
M:N models. Both models requires the kernel to know about "threads".
Regards,
Loic
David Schwartz
> I can't understand why a 1:1 model would mean automatically a system
> contension scope? Couldn't we design a scheduler which knows about
> groups of kernel threads representing a process?
With the standard UNIX scheduling scheme, there is no obvious reason
why you wouldn't want system contention scope. Even if you had a more
specialized 'fair' scheduler that, for example, took users into account,
it still isn't obvious why a user's threads should be treated
differently from their processes.
Imagine I change a program's design from using four processes to using
four threads. Please give me one good reason why it should suddenly get
only 1/4 the CPU it got before.
DS