Date: Sat, 23 Sep 2000 10:55:12 -0700 (PDT) From: John Baldwin <jhb@freebsd.org> To: Chuck Paterson <cp@bsdi.com> Cc: alpha@freebsd.org, smp@freebsd.org Subject: Re: Status update Message-ID: <200009231755.KAA51845@john.baldwin.cx> In-Reply-To: <200009231727.LAA17839@berserker.bsdi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 23-Sep-00 Chuck Paterson wrote: > > 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. Hmm, ok. Currently the only thing we were using from the ithd structure was the it_need flag (like the runstatus flag in BSD/OS' ithreads) to know when to keep looping. I changed it to just use spending for this. It is still scheduled and ran using a method similar to the hardware ithreads, it just doesn't have a ithd struct. However, it is quite easy to add the ithd struct back in when we go to light-weight context switches. > }- 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? It just happens on the alpha, it doesn't happen on the x86. I'm not sure where it is happening though. If we are sure of that guarantee (interrupts should always be enabled before grabbing sched_lock and calling either cpu_switch or mi_switch) then that should make my KASSERT()'s to find this easier, and I can get rid of this code. > 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. Currently all SWI's are now triggered by setting the appropriate bit in spending and calling sched_softintr() to make the softinterrupt thread runnable. sched_softintr() is very similar in functionality to sched_ithd in the x86 hardware interrupt code. > Chuck -- John Baldwin <jhb@FreeBSD.org> -- 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?200009231755.KAA51845>