Subject: Re: SCHED_LOCK(9)?
To: None <tech-kern@netbsd.org>
From: Andrew Doran <ad@netbsd.org>
List: tech-kern
Date: 04/21/2007 14:01:13
Hi Oliver,
On Fri, Apr 20, 2007 at 11:26:36PM -0400, Oliver Gould wrote:
> kqemu_schedule() is more-or-less the old sys/kern/kern_synch.c:yield()-
> except KQEMU wants to prioritize itself. Eg:
>
> int
> kqemu_schedule(void)
> {
> struct lwp *l;
> int s;
>
> l = curlwp;
>
> s = SCHED_LOCK();
> l->l_priority = MAXPRI;
> l->l_stat = LSRUN;
> setrunqueue(l);
> l->l_proc->p_stats->p_ru.ru_nvcsw++;
> mi_switch(l, NULL);
> splx(s);
>
> return issignal(curlwp) != 0;
> }
>
>
> Will mimicking the new yield() work similarly?
Yup, with l->l_usrpri replaced with MAXPRI. The call to issignal() needs the
process' signal state locked. For now issignal() also needs the kernel_lock
held as it may free memory. If you're sure that keqmu_schedule() will only
ever be called with the kernel_lock held then the following will work:
KERNEL_LOCK(l->l_biglocks, l);
mutex_enter(&p->p_smutex);
sig = issignal(l);
mutex_exit(&p->p_smutex);
return sig != 0;
I'm curious what it uses the return value for, but the above seems to match
what keqmu_schedule() does for FreeBSD.
Andrew