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 [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Reply via email to