cvs commit: src/sys/cam/scsi scsi_target.c src/sys/coda coda_psdev.c src/sys/dev/aac aac.c src/sys/dev/bktr bktr_core.c src/sys/dev/firewire firewire.c src/sys/dev/kbd kbd.c src/sys/dev/nmdm nmdm.

[Seigo Tanimura]

On Mon, 10 Nov 2003 18:14:14 +1100 (EST),
  Bruce Evans <bde at zeta.org.au> said:

bde> On Sun, 9 Nov 2003, John Baldwin wrote:
>> On 09-Nov-2003 Seigo Tanimura wrote:
>> > tanimura    2003/11/09 01:17:26 PST
>> >
>> >   FreeBSD src repository
>> >
>> >   Modified files:
>> >     sys/cam/scsi         scsi_target.c
>> >     sys/coda             coda_psdev.c
>> > ...
>> >   Log:
>> >   - Implement selwakeuppri() which allows raising the priority of a
>> >     thread being waken up.  The thread waken up can run at a priority as
>> >     high as after tsleep().
>> >
>> >   - Replace selwakeup()s with selwakeuppri()s and pass appropriate
>> >     priorities.
>> >
>> >   - Add cv_broadcastpri() which raises the priority of the broadcast
>> >     threads.  Used by selwakeuppri() if collision occurs.
>> >
>> >   Not objected in:        -arch, -current
>> 
>> Sorry I didn't speak up on arch@, just too busy.  But, why do you need
>> to bump up the priority of the thread you are waking up?

bde> I left the reply to someone else :-).

bde> The priority may need to be bumped because the thread is a user thread that
bde> is sleeping at a low user priority.  As I understand this change, the
bde> thread priority may be low for cases that don't use tsleep() so they can't
bde> set the thread priority using that.  So this changes is needed to get the
bde> same behaviour as using tsleep().  However, I think that behaviour is not
bde> quite right -- if the thread is a user thread then it waking it up is only
bde> urgent if it needs to do some urgent things in kernel mode on wakeup.  It
bde> should not return to user mode until its user priority permits its
bde> scheduling.  However2, we still have the bugfeature that user threads keep
bde> the kernel priority that they wake up at all the way back to user mode,
bde> and this may be necessary for interactivity.

I could implement priority bumping in selwakeuppri(), but I thought it
would be troublesome to tweak struct cv outside kern_condvar.c.

In case of select(2) et. al., selecting threads waken up repolls file
descriptors.  As it is a in-kernel work, those threads should remain
at in-kernel priorities until polling succeeds, aren't they?

-- 
Seigo Tanimura <tanimura at tanimura.dyndns.org> <tanimura at FreeBSD.org>