Date: Tue, 11 Nov 2003 14:19:42 +0900 From: Seigo Tanimura <tanimura@tanimura.dyndns.org> To: Bruce Evans <bde@zeta.org.au> Cc: John Baldwin <jhb@freebsd.org> Subject: Re: 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. Message-ID: <200311110519.hAB5JgFX008891@urban> In-Reply-To: <20031111040413.V717@gamplex.bde.org> References: <XFMail.20031109194035.jhb@FreeBSD.org> <20031110180540.P2148@gamplex.bde.org> <200311101217.hAACH9FZ001752@urban> <20031111040413.V717@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 11 Nov 2003 04:16:15 +1100 (EST), Bruce Evans <bde@zeta.org.au> said: bde> On Mon, 10 Nov 2003, Seigo Tanimura wrote: >> On Mon, 10 Nov 2003 18:14:14 +1100 (EST), >> Bruce Evans <bde@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? bde> I think there is no need for elevated kernel priority in select() if bde> threads drop back to their normal user priority on return to user mode, bde> since nothing (?) except the user process is affected by the results bde> of select() (unlike for some i/o operations). Note that the priority That would hold if a thread waken up went straightly back to user mode. bde> is not elevated at the start of select(), so processes can be preempted bde> there now that we have a semi-preempive kernel. Why should the bde> completion of select() be different if the thread needed to sleep? bde> Any increase in priority should be because the thread slept for a while bde> and not arbitrary. We may need some tricks to protect all of the file descriptors being polled in kern_select(). -- Seigo Tanimura <tanimura@tanimura.dyndns.org> <tanimura@FreeBSD.org>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200311110519.hAB5JgFX008891>