kit@falstaf.SanDiego.NCR.COM (Kit Chow) (02/15/89)
1) If a user process can be 'nailed' into memory, is there still a need to copyin(k) data from user virtual address space into kernel address space? If no, could the kernel then access the user data in the user virtual address space with minimum overhead? 2) What exactly does wakeup(k) do to move processes from the SLEEP state to the READY state? Is there a different linked list of SLEEPing and READY processes? If no, does the scheduler traverse through the entire proc array to find the next READY process to run?
chris@mimsy.UUCP (Chris Torek) (02/15/89)
In article <885@ncr-sd.SanDiego.NCR.COM> kit@falstaf.SanDiego.NCR.COM (Kit Chow) writes: >1) If a user process can be 'nailed' into memory, is there still a >need to copyin(k) data from user virtual address space into kernel >address space? If no, could the kernel then access the user data >in the user virtual address space with minimum overhead? A) no, and b) yes, and in fact this is what `raw I/O' does. The details are quite machine-dependent, however. For instance, some hardware requires that all I/O addresses be physically contiguous, which will probably be false in a demand-paging system. Other hardware can only talk to a specific (limited) address space. >2) What exactly does wakeup(k) do to move processes from the >SLEEP state to the READY state? Mark it runnable and put it into the run queue. This is another place that things are likely to vary between different kernels. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
guy@auspex.UUCP (Guy Harris) (02/16/89)
>>1) If a user process can be 'nailed' into memory, is there still a >>need to copyin(k) data from user virtual address space into kernel >>address space? If no, could the kernel then access the user data >>in the user virtual address space with minimum overhead? > >A) no, and b) yes, and in fact this is what `raw I/O' does. Well, sort of. When doing "raw I/O" the kernel generally doesn't even touch the data; it lets the I/O subsystem do so (which is why the details are machine-dependent, as indicated). If kernel code wants to access the data directly, that's *also* machine-dependent; some systems provide separate address spaces for kernel-mode and user-mode code (e.g. a Sun-2), which means that user-mode virtual address N and kernel-mode virtual address N refer to different physical addresses, and there may not *be* a kernel-mode virtual address that refers to the same physical address as user-mode virtual address N. In addition, of course, the kernel may or may not want to access the data directly; for instance, it may have write permission on some location that the user does *not* have write permission on, and if it's doing stuff on behalf of the user, it may not want to modify a location for the user process if it can't modify it itself.