On Wed, Oct 04, 2000 at 06:16:57PM -0300, Rik van Riel wrote:
> > > ---
> > > One way would be to set a flag "I'm holding a lock" and when
> > > it releases the lock(s), deschedule it?
> >
> > There is a well-known name for this -- priority inversion.
> >
> > Implement the whole shebang of starvation avoidance tricks,
> > and we can whak the scheduler to group processes into separate
> > subsets, which in current system leads to starvation lockups.
> >
> > A thing for 2.5 ? (With possible backport to 2.4 latter.)
>
> We don't need that.
>
> We just need one boolean per thread ... is it holding a kernel
> lock or not?
The BKL or *any* (kernel) lock ?
For my knowledge there is no limitation on how many
locks a thread can hold. Having a single bool might
not be enough. A counter is better ?
For example: Two filesystems are locking on their respective
superblocks, and then they are locking on some underlying IO
facility which both are sharing.
Should the lock-count be incremented before the lock acquisition
has happened, or only afterwards, that is other story.
> If it is, make sure its scheduling latency isn't too high.
e.g. all processes having *any* locks are raised to the highest
possible class to make sure they are not starved out ?
> If it isn't holding any lock, we can do with it what we want,
> including completely starving the task for several seconds
> (or even minutes) if scheduling latency or VM pressure warrants
> it.
Yes, that is obvious.
> regards,
>
> Rik
> http://www.conectiva.com/ http://www.surriel.com/
/Matti Aarnio
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Oct 07 2000 - 21:00:15 EST