From owner-freebsd-alpha Tue Jan 2 12: 6:53 2001 From owner-freebsd-alpha@FreeBSD.ORG Tue Jan 2 12:06:48 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 13FA737B402 for ; Tue, 2 Jan 2001 12:06:48 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id f02K6VG01719 for ; Tue, 2 Jan 2001 12:06:31 -0800 (PST) (envelope-from john@baldwin.cx) Resent-Message-Id: <200101022006.f02K6VG01719@meow.osd.bsdi.com> Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Resent-Date: Mon, 06 Nov 2000 16:12:46 -0800 (PST) Resent-From: John Baldwin Resent-To: Matthew Jacob Date: Tue, 02 Jan 2001 12:06:55 -0800 (PST) From: John Baldwin To: alpha@FreeBSD.org Subject: Disabling ints via IPL Resent-Sender: john@baldwin.cx Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Installment 2: On 07-Nov-00 Matthew Jacob wrote: >> >> > This makes it more problematic for the scheduler because it's got to be >> > able >> > to let interrupt thread run to completion (dropping of mutexes). In fact, >> > there's a tremendous body of work, both theoretical and actual (see Thoth, >> > Auspex's m16, etc), that state that scheduling primary interrupt threads >> > (as >> > opposed to offlevel processing) is just not productive- so that the only >> > 'scheduling' that should be done at interrupt level is to make sure that >> > the >> > priorities aren't tangled. >> >> It's not really hard for the scheduler. The kernel is not pre-emptible at >> the moment. We don't handle an need_resched() posted by the clock >> interrupt until we return to userland. > > But you do need to do some kind of implicit scheduling. Hmm, you miss that as far as I have seen at least, all the device I/O interrupts (the only ones we thread) are all triggered at the same IPL, so all interrupt threads would end up running at the same IPL, and you wouldn't get another threaded interrupt until the last interrupt's handler executes and finishes. All the blocking and rescheduling does happen in the mutex code (and yes, we will run the new thread that just got the mutex on a mtx_exit() immediately if the new thread has the higher priority). > There then becomes the further problem, which is what can lead to livelock- > this is when you are running an ithread where you try and grab another mutex. > > In this case, the rules that you simply transfer the IPL to the thread that > holds the lock aren't so simple because you have to do some scheduling > checking so that you don't do something lame like continue to run X because Z > tried to grab another mutex held by X. But you can't run X because there's a > lock held by Z, and so on. So the IPL transferrence only works in non-nested > locking cases I think. Basically, as far as I can tell, the kernel would run with the raised IPL until the handler finishes and returns, so all other device interrupts will be on hold and you won't have 1 interrupt thread blocked on a mutex that another interrupt thread holds. You would only have an interrupt thread waiting for a top-half thread to finish using a resource. Otherwise there is nothing to prevent an interrupt source from firing over and over and over again unless you use the disable/enable calls. > -matt -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message