[nptl] Re: http://bugme.osdl.org/show_bug.cgi?id=3770

[Sebastien Decugis <sebastien.decugis@ext.bull.net>]

> >What is your opinion?
> >
> >
> 
> My opinion is that it is much nicer if we are able to keep it as per-cpu.
> 
> I believe Ingo, Linus, etc. agreed that this was a valid interpretation
> of the relevant standards. I haven't personally looked myself, but I suspect
> that there would be a *very* large opposition to making the RT list global.
> 
> It would be harmful to scheduler scalability and simplicity.

This means that specifying the tasks priority and the scheduling policy
is useless on SMP machines... As you won't get the expected behavior. I
think this can lead to random hangs in RT applications.

I don't know the kernel internals, but I think there already is a
mechanism to move processes from a CPU to another. In case of SCHED_RR
or SCHED_FIFO policy, my opinion is that you'd have to use the whole
pool of resources -- otherwise you cannot guarantee that the higher
process will execute in priority on the lower process.

Consider the following situation in SCHED_RR policy:
CPU A:
Process 1 priority 20
Process 2 priority 25

CPU B:
Process 3 priority 30
Process 4 priority 35

In this situation, with the current kernel, you'd have a priority-25
process running whereas a priority-30 is waiting? I think this is
clearly a bug!

The default scheduling policy, SCHED_OTHERS, is implementation-defined;
but for applications using SCHED_FIFO or SCHED_RR, I think such behavior
is unacceptable. If scalability or simplicity suffers from this, this
can't be helped IMHO, it is better than having hangs in the application
because of the scheduler.

I still consider this as a bug, and I'd like to hear from RT
programmers...

Regards,
Seb.


-- 
-------------------------------
Sebastien DECUGIS
NPTL Test & Trace Project
http://nptl.bullopensource.org/

"You may fail if you try.
You -will- fail if you don't."

Liste de diffusion nptl
Pour se désinscrire : mailto:nptl_request@bullopensource.org?subject=unsubscribe