allen@capone.UUCP (Allen Brumm) (08/27/89)
I have two questions/concerns regarding the low level context switch routine (swtch()) in 4.[23]BSD systems. When a process exits, it frees its pages of u-area and kernel stack by calling vrelu(). Either before this call, or within vrelu() itself (depending on whether you are using 4.2 or 4.3) the IPL is raised to block out network interrupts (splimp()). The intent of raising the IPL is to not allow memory allocation in the network code, in particular, to avoid a page of mbufs being allocated in a network interrupt routine. The problem that I see is that after exit calls vrelu() and finishes the rest of its work, it then calls swtch(). Swtch() idles at a low IPL in the context of the exit'ing process. While swtch() is idling at a low IPL, what is to prevent a network interrupt from coming in and allocating the page which corresponded to the exit'ing processes u-area? When swtch() finds a process ready to run and emerges from the idle loop it still expects the exit'ing processes u-area page to belong to the exit'ing process. It does a svpctx instruction which writes the pcb at the beginning of the u-area, and it saves the CMAP2 entry in the u-area. If this page had been re-allocated by a network interrupt routine, a possibility exists of destroying a page of mbufs (or at least part of it). This is probably an unlikely event since the u-area pages and kernel stack freed by the exit'ing process are put at the end of the free list. But it is still possible as far as I can tell. So my question is: Is there something that prevents the above scenario from occurring which I am failing to notice? If so, please let me know. My second question is something that has bothered me for quit a while (not very much though) and has to do with the assignment of sleep priorities in 4.[23]BSD. Since the sleep priorities range from 0-127 and are divided by 4 to fit in the range of 0-31. Presumably for the purpose of the using the VAX 'ffs' instruction on the variable whichqs. Sleep priorities which fall into the same runq position are treated equally (after the division). It would seem that if you truly want an event completion/notification to have a higher priority over some other event completion/notification you must make sure that the sleep priority used will divide to a higher (lower) runq position relative to the other event. This is fine. What bothers me is the assignment of TTIPRI (28), and TTOPRI (29). The intent being to treat input notification with a higher priority than output completion (receive over transmit) then the two (or more) processes should be placed on different runq positions. Both 28 and 29 divide by 4 to equal 7. It seems as though 27 and 28 would be better choices. Any comment? Thanks Allen Brumm uunet!ccicpg!capone!allen