Date: Sat, 23 Sep 2000 11:27:51 -0600 From: Chuck Paterson <cp@bsdi.com> To: John Baldwin <jhb@freebsd.org> Cc: smp@freebsd.org, alpha@freebsd.org Subject: Re: Status update Message-ID: <200009231727.LAA17839@berserker.bsdi.com> In-Reply-To: Your message of "Sat, 23 Sep 2000 00:34:22 PDT." <XFMail.000923003422.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John, } }- software interrupts (SWI's) are now MI except for a few constants. } Currently we still only have 8 SWI's on the x86 due to old compatability } nonsense. We should be able to bump this to 32 like it is on the alpha very } easily if it proves beneficial. Also software interrutps are completely } divorced from the x86 hardware interrupt code. The softinterrupt thread is } also now a simple kthread instead of an ithread. I guess I'm a little unclear about this. We certainly don't want any hardware goop with software interrupts, at least in the case where there is no hardware support of software interrupts, but it seems like we do want them to be more than just another kthread, we want to be able to schedule them on the fly like hardware interrupts and do light weight context switches to them. Am I missing something? }- The interrupt state of the sched_lock is now saved in a process's PCB during } cpu_switch(). This way, code before and after a call to either mi_switch() } or cpu_switch() is guaranteed to be run at the same interrupt state. Without } this I was having problems on the alpha where the idle loop was running at } ALPHA_PSL_IPL_SOFT (1) and as a result init's child process was never ran, } among other things. BSD/OS on Sparc actually has interrupt levels that are associated with some mutexs. However the code that uses these levels are always using spin locks so there isn't an issue. Whenever cpu_switch is called all interrupts are blocked, but the spl level, which it think is ~= interrupt state is not raised at all. On sparc these are use for the low level code in for devices like the com driver. I guess the first question is why there is any kernel code calling switch with the interrupt priority up. This sounds like it may be a result of software interrupts being changed into kthreads? If alpha has hardware support for software interrupts then we might be able to treat them fully like hardware interrupts. The case in BSD/OS where a software interrupt is scheduled and the no switch flag is passed in will just work, the reason for the no switch is because the thread currently holds spins locks, which in the case of hardware supported interrupts should be blocked anyway. Chuck Chuck 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?200009231727.LAA17839>