On Mon, 18 Feb 2002, Matthew Dillon wrote:
[...]
>
> It turns out that the two processes got into an extremely non-optimal
> contested/sleep/wakeup situation, even though they do not actually have
> to sleep on Giant in this situation.
>
> The solution is to allow _mtx_lock_sleep() to spin instead of sleep in
> the situation where: (1) there are no runnable processes other then
> the ones already running on a cpu, (2) interrupts are enabled, and
> (3) the mutex in question is not contested (to avoid starving the thread
> contesting the mutex). In this case we can spin.
it's possible John's preemption code may also handle this..
>
> -Matt
>
> Index: kern/kern_mutex.c
> ===================================================================
> RCS file: /home/ncvs/src/sys/kern/kern_mutex.c,v
> retrieving revision 1.80
> diff -u -r1.80 kern_mutex.c
> --- kern/kern_mutex.c 18 Feb 2002 17:51:47 -0000 1.80
> +++ kern/kern_mutex.c 18 Feb 2002 19:11:17 -0000
> @@ -287,7 +287,9 @@
> _mtx_lock_sleep(struct mtx *m, int opts, const char *file, int line)
> {
> struct thread *td = curthread;
> +#if 0
> struct ksegrp *kg = td->td_ksegrp;
> +#endif
>
> if ((m->mtx_lock & MTX_FLAGMASK) == (uintptr_t)td) {
> m->mtx_recurse++;
> @@ -312,6 +314,22 @@
> * the sched_lock.
> */
> if ((v = m->mtx_lock) == MTX_UNOWNED) {
> mtx_unlock_spin(&sched_lock);
> continue;
> }
> +
> + /*
> + * Check to see if there are any runnable processes. If
> + * there aren't and nobody is contesting the mutex (to avoid
> + * starving a contester) and interrupts are enabled, then
> + * we can safely spin.
> + *
> + * This prevents a silly-sleep-flip-flop situation on SMP
> + * systems where two running processes need Giant (or any
> + * other sleep mutex).
> + */
> + if (td->td_critnest == 0 && (v & MTX_CONTESTED) == 0 &&
> + procrunnable() == 0) {
> + mtx_unlock_spin(&sched_lock);
> + continue;
> + }
I can't see any major problem with this but I can't help thinking that
there must be one.. on UP the question is: "who is going to
release the lock if no-one is runnable?"
can you detail in more clarity the flip-flopping you were seeing?
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
