Date: Mon, 10 Nov 2003 21:17:09 +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: <200311101217.hAACH9FZ001752@urban> In-Reply-To: <20031110180540.P2148@gamplex.bde.org> References: <XFMail.20031109194035.jhb@FreeBSD.org> <20031110180540.P2148@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 10 Nov 2003 18:14:14 +1100 (EST), Bruce Evans <bde@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@tanimura.dyndns.org> <tanimura@FreeBSD.org>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200311101217.hAACH9FZ001752>