cvs commit: src/sys/cam/scsi scsi_target.c src/sys/codacoda_psdev.csrc/sys/dev/firewire firewire.c src/sys/dev/kbd kbd.c src/sys/dev/nmdm nmdm.

[Bruce Evans]

On Mon, 10 Nov 2003, Seigo Tanimura wrote:

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

> ...
> 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?

I think there is no need for elevated kernel priority in select() if
threads drop back to their normal user priority on return to user mode,
since nothing (?) except the user process is affected by the results
of select() (unlike for some i/o operations).  Note that the priority
is not elevated at the start of select(), so processes can be preempted
there now that we have a semi-preempive kernel.  Why should the
completion of select() be different if the thread needed to sleep?
Any increase in priority should be because the thread slept for a while
and not arbitrary.

Bruce