Re: static scheduling - SCHED_IDLE?

From: Adrian Cox <adrian@humboldt.co.uk>
To: george anzinger <george@mvista.com>
Cc: Rik van Riel <riel@conectiva.com.br>,
	Boris Dragovic <lynx@falcon.etf.bg.ac.yu>,
	Oswald Buddenhagen <ob6@inf.tu-dresden.de>,
	linux-kernel@vger.kernel.org
Subject: Re: static scheduling - SCHED_IDLE?
Date: Fri, 09 Mar 2001 20:19:10 +0000	[thread overview]
Message-ID: <3AA93ABE.7000707@humboldt.co.uk> (raw)
In-Reply-To: <Pine.LNX.4.33.0103081747010.1314-100000@duckman.distro.conectiva> <3AA93124.EC22CC8A@mvista.com>

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