Messages in this thread | | | Date | Wed, 11 Nov 1998 02:58:47 +0100 (CET) | From | MOLNAR Ingo <> | Subject | Re: SCHED_IDLE patch is a source of DoS |
| |
On Tue, 10 Nov 1998, Rik van Riel wrote:
> > This _is_ basically the 'classic' fix mentioned - the process > > holding the lock(s) attains the higher priority for the duration.
the problem is that there is no easy central way to determine wether a process 'holds some valuable resource'.
> The goodness() piece will look approximately > like this: > > if (p->policy == SCHED_OTHER) { > if (p->lock_depth >= 0) > return 1; > else > return -1; > }
lock_depth is something very different ... It's not even a lock. (lock_depth >= 0 has little or no meaning at all to any other process if this process is not running) There are many different kinds of locks within Linux, and there are many informal (nonexplicit) ways of locking too. (set a static local flag if not set yet, reschedule if already set)
if we want to do this, it's a major overhaul, definitely a 2.3 item. (just think read-write semaphores ... we do not have them currently, but it would be very hard and ineffective to make them priority-aware)
-- mingo
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |