From owner-cvs-src@FreeBSD.ORG Mon Nov 10 05:37:06 2003 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 51AC816A4CE; Mon, 10 Nov 2003 05:37:06 -0800 (PST) Received: from sohgo.tanimura.dyndns.org (IP1A0600.kng.mesh.ad.jp [211.13.103.220]) by mx1.FreeBSD.org (Postfix) with ESMTP id BEC3643FD7; Mon, 10 Nov 2003 05:37:02 -0800 (PST) (envelope-from tanimura@tanimura.dyndns.org) Received: from sohgo.tanimura.dyndns.org (localhost [IPv6:::1]) ESMTP id hAADavd0032751 ; Mon, 10 Nov 2003 22:36:57 +0900 (JST) Received: (from uucp@localhost) (8.12.9/3.7W-submit-carrots-Tokyu-Meguro) with UUCP id hAADauPs032747 ; Mon, 10 Nov 2003 22:36:56 +0900 (JST) Received: from urban.nkth.tanimura.dyndns.org (localhost [IPv6:::1]) with ESMTP id hAACH9FZ001752 ; Mon, 10 Nov 2003 21:17:10 +0900 (JST) Message-Id: <200311101217.hAACH9FZ001752@urban> Date: Mon, 10 Nov 2003 21:17:09 +0900 From: Seigo Tanimura To: Bruce Evans In-Reply-To: <20031110180540.P2148@gamplex.bde.org> References: <20031110180540.P2148@gamplex.bde.org> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 MULE XEmacs/21.4 (patch 13) (Rational FORTRAN) (i386--freebsd) Organization: My Home MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII cc: cvs-src@FreeBSD.org cc: Seigo Tanimura 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/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. X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2003 13:37:06 -0000 X-List-Received-Date: Mon, 10 Nov 2003 13:37:06 -0000 On Mon, 10 Nov 2003 18:14:14 +1100 (EST), Bruce Evans 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