From owner-cvs-all@FreeBSD.ORG Mon Nov 10 09:16:51 2003 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4998516A4CE; Mon, 10 Nov 2003 09:16:51 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id A281143FA3; Mon, 10 Nov 2003 09:16:39 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id EAA13045; Tue, 11 Nov 2003 04:16:18 +1100 Date: Tue, 11 Nov 2003 04:16:15 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Seigo Tanimura In-Reply-To: <200311101217.hAACH9FZ001752@urban> Message-ID: <20031111040413.V717@gamplex.bde.org> References: <20031110180540.P2148@gamplex.bde.org> <200311101217.hAACH9FZ001752@urban> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Seigo Tanimura cc: cvs-src@freebsd.org cc: src-committers@freebsd.org cc: cvs-all@freebsd.org cc: John Baldwin Subject: Re: 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. X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2003 17:16:51 -0000 On Mon, 10 Nov 2003, Seigo Tanimura wrote: > On Mon, 10 Nov 2003 18:14:14 +1100 (EST), > Bruce Evans 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