On Thu, 22 Jun 2006, Thomas Gleixner wrote:
On Thu, 2006-06-22 at 00:35 +0100, Esben Nielsen wrote:
On Wed, 21 Jun 2006, Thomas Gleixner wrote:
On Wed, 2006-06-21 at 22:29 +0100, Esben Nielsen wrote:
Find an version against the code in -mm below. Not too much tested yet.
What if setscheduler is called from interrup context as in the hrt timers?
It simply gets stuff going, nothing else.
What I mean is that we will then do the full priority inheritance boost
with interrupts off.
Only in the case when its called from IRQ context.
Before setscheduler() was O(1), now it is O(<lock depth of what ever lock
the target task might be locked on>).
This is not a problem for your use of setscheduler() as the task involved
only can be blocked on kernel mutexes, but when the function is used on a
userspace process the lock depth can be deep.
Damn, I missed that this is still in the irq off section, when called
from do_sched_setscheduler().
There is more to it than that:
What if you for some reason try to set the priority of a low level task
from a high priority one? It could be that your application have some kind
of watchdog or manager process dynamically adjusting the priorities of the
other tasks. You simply don't want to be concerned about those tasks being
blocked in some strange (maybe even buggy) logging structure. You want to
do it O(1) and then let those tasks handle it.
Good catch. I fix that.
I know you hate to let the scheduler do the work for you, but I find it
very elegant and easy once in a while :-)
Esben
tglx
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
