Date: Tue, 02 Jan 2001 12:06:55 -0800 (PST) From: John Baldwin <john@baldwin.cx> To: alpha@FreeBSD.org Subject: Disabling ints via IPL Message-ID: <XFMail.010102120655.john@baldwin.cx> Resent-Message-ID: <200101022006.f02K6VG01719@meow.osd.bsdi.com>
next in thread | raw e-mail | index | archive | help
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 <john@baldwin.cx> -- 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.010102120655.john>