lkml.org 
[lkml]   [2001]   [Mar]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: static scheduling - SCHED_IDLE?
From
> The problem with these things it that sometimes such a task may hold
> a lock, which can prevent higher-priority tasks from running.
>
true ... three ideas:
- a sort of temporary priority elevation (the opposite of SCHED_YIELD)
as long as the process holds some lock
- automatically schedule the task, if some higher-priorized task wants
the lock
- preventing the processes from aquiring locks at all (obviously this
is not possible for required locks inside the kernel, but i don't
know enough about this)

> A solution would be to make sure that these tasks get at least one
> time slice every 3 seconds or so, so they can release any locks
> they might be holding and the system as a whole won't livelock.
>
did "these" apply only to the tasks, that actually hold a lock?
if not, then i don't like this idea, as it gives the processes
time for the only reason, that it _might_ hold a lock. this basically
undermines the idea of static classes. in this case, we could actually
just make the "nice" scale incredibly large and possibly nonlinear,
as mark suggested.

best regards

--
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
--
Nothing is fool-proof to a sufficiently talented fool.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:29    [W:0.114 / U:1.464 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site