From owner-freebsd-alpha Tue Jan 2 12: 7: 4 2001 From owner-freebsd-alpha@FreeBSD.ORG Tue Jan 2 12:06:59 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 D6A1737B699 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 f02K6WG01731 for ; Tue, 2 Jan 2001 12:06:32 -0800 (PST) (envelope-from john@baldwin.cx) Resent-Message-Id: <200101022006.f02K6WG01731@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: Fri, 17 Nov 2000 11:39:32 -0800 (PST) Resent-From: John Baldwin Resent-To: Andrew Gallatin Date: Tue, 02 Jan 2001 12:06:56 -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 Part V: this has a bit more meat in the explanation.. On 17-Nov-00 Andrew Gallatin wrote: > > John Baldwin writes: > > Ugh. Yuck. Hmm. We need that ast() so that we switch to the interrupt > > thread, too (we will need it for light-weight ithreads as well). We > should > > probably lower the IPL to the saved IPL in the stack frame instead. It > will > > always be zero except for this hack for pc164's (since this is only done > when > > returning to userland, which runs at IPL 0). Hmm. Actually, we will want > to > > restore the saved IPL in the frame to 0 after this inside of ast() (since > ast() > > is going to switch to the itnerrupt thread, and we will be back at IPL 0 > when > > we return). So, what we really need to modify is not the IPL we switch to > on > > return, but the IPL we use here before calling ast(). > > That should make things a little easier. > > I'm still trying to understand what's going on here... What happens if > the interrupt thread blocks? Does a context switch happen and the > next process continue to run on the interrupt stack until such time as > the original interrupt thread runs to completion? No, the interrupt thread has its own stack (it is a kernel process), so the next process continues to run in its own context. The raised IPL will be propagated via sched_lock, however, and will stay raised until it is lowered via ithd_loop(). The assumption is that your userland process is not going to resume until after this has happened (otherwise the IPL would drop down again and *boom*). This assumption should be safe because interrupt threads have a very high priority, and if an ithread blocks on a mutex, its priority will be propagated (once that code works :-P) to the process holding the mutex. That process will be in the kernel, so it won't be the userland process we just interrupted. Hmm, if we get an interrupt in the kernel though we need to modify the saved IPL in the frame. Ugh, ok. Then go back to the original proposal (modify the IPL in the frame). In the ast() case in exception_return, we swap IPL_0 (we know 0 is ok, because we were interrupted from userland) with the saved IPL in the stack frame, and then set the IPL to the one we just got out of the saved stack frame. Since ithreads only block for SMP, and due to priority propagation and the high priority of ithreads, the userland process won't run again until the ithread has completed and run. We will only be running processes that are in the kernel. Once a process in the kernel releases the mutex that the ithread is blocked on, it will resume its normal priority, and the ithread will run immediately (since the ithread has higher priority), dropping the IPL back down. The process in the kernel won't return to userland without dropping the lock, so userland won't ever be running at an IPL other than 0. Note that ithreads will only block and priority propagation only needs to work in the SMP case. The only way an ithread will block in the UP case is if the interrupted process is in the kernel, and it will run next (since it is the second highest priority since it was just chosen to run last) and eventually release the lock enabling the ithread to run and lower the IPL. whew.. > Drew -- As a side note, if IPL is across all CPU's, then on an SMP machine, it might be possible that while one CPU is running the interrupt handler, another CPU will be running a userland process at a raised IPL, but I don't think there is anythign we can do about that, and I don't think it will hurt us since the only thing that really cares about/is affected by the IPL is the kernel. -- 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