Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 20 Sep 2001 10:38:07 -0700 (PDT)
From:      John Baldwin <jhb@FreeBSD.org>
To:        Julian Elischer <julian@elischer.org>
Cc:        arch@freebsd.org, julian@FreeBSD.org
Subject:   Re: cvs commit: src/sys/kern kern_mutex.c
Message-ID:  <XFMail.010920103807.jhb@FreeBSD.org>
In-Reply-To: <3BA9406D.2BD9DFDF@elischer.org>

next in thread | previous in thread | raw e-mail | index | archive | help

On 20-Sep-01 Julian Elischer wrote:
> 
> John Baldwin wrote:
>> 
>> On 19-Sep-01 John Baldwin wrote:
>> > jhb         2001/09/19 15:52:59 PDT
>> >
>> >   Modified files:
>> >     sys/kern             kern_mutex.c
>> >   Log:
>> >   Fix a bug in propagate priority: the kse group pointer wasn't being
>> >   updated in the loop so the new thread always seemd to have the same
>> >   priority as the original thread and no actual priorities were changed.
>> 
>> As a sort of follow-up, Julian, can you explain why the oncpu == NOCPU test
>> to
>> see if a thread is currently running (i.e., physically executing thus it's
>> not
>> on a runqueue and there's nothing we can do to make it run any sooner) is
>> insufficient per new comments in the code?
> 
>  if (td->td_kse && (td->td_kse->ke_oncpu != NOCPU)) {
> 
> The above test does not say that the thread is running,
> only that the KSE is running. Which thread is running needs to be 
> found out from td->td_kse->ke_thread. In the 1:1 case this is
> enough but when we add code to schedule threads onto KSEs
> then the test must be expanded if we really want to know whether a 
> thread is running..

Ah.

> It is of course possible that what thread is running is not
> so important as whether the kse is running. What we need to decide
> is exactly what happens with proiority  chages that are given to a thread..
> does the KSE ket itfo rthe entire tick? for just the time that thread
> (syscall)
> is running?
> priority scope is something we have not really discussed yet.

Nah, the thread holds the lock, so it is the thread's priority which must be
bumped.  In this sense, bumping the kse group priority is wrong.  Qutie
possibly what should happen is that the the pri_native and pri_user priorities
should be in the ksegroup but that the actual priority should be in the thread
since priority propagation just wants to ensure that the thread holding a
resource we need will run soon.  If other threads from the same ksegroup run
first that doesn't really help.

-- 

John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.010920103807.jhb>