george anzinger wrote:
> Seems like you are sneaking up on priority inherit mutexes. The locking
> over head is not so bad (same as spinlock, except in UP case, where it
> is the same as the SMP case). The unlock is, however, the same as the
> lock overhead. It is hard to beat the store of zero which is the
> spin_unlock.
Unfortunately the kernel is already full of counting semaphores.
Priority inheritance won't save you, as the task which is going to call
up() need not be the same one that called down().
Jamie Lokier's suggestion of raising priority when in the kernel doesn't
help. You need to raise the priority of the task which is currently in
userspace and will call up() next time it enters the kernel. You don't
know which task that is.
There are three solutions I can think of:
1) don't have SCHED_IDLE
2) promote all SCHED_IDLE tasks into SCHED_OTHER whenever *any* task is
waiting on a semaphore.
3) an audit of semaphores for 2.5
I'm quite fond of option 1.
- Adrian
-
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/
This archive was generated by hypermail 2b29 : Thu Mar 15 2001 - 21:00:11 EST