paul@vixie.UUCP (05/12/87)
According to Bach, UNIX(tm) rearranges the kernel's virtual address space
to make the 'u' structure variable map to the current process' u-area. This
requires that the U area be page-aligned and a multiple of pagesize long,
which sounds a little bit difficult to do. But that's not my question...
Mapping the u-area onto 'u.' certainly makes references quicker than using a
structure pointer, since there is one less memory reference before getting to
members of the structure. What I wonder is, how much jumbling is required to
re-map the page, and is the trade-off worth it? Just how much is 'u.' used
between context switches, anyway?
--
Paul A. Vixie {ptsfa, crash, winfree}!vixie!paul
329 Noe Street dual!ptsfa!vixie!paul@ucbvax.Berkeley.EDU
San Francisco
CA 94116 paul@vixie.UUCP (415) 864-7013lm@cottage.WISC.EDU (Larry McVoy) (05/12/87)
In article <626@vixie.UUCP> paul@vixie.UUCP (Paul Vixie Esq) writes: >re-map the page, and is the trade-off worth it? Just how much is 'u.' used >between context switches, anyway? I daresay that it used every single time you enter the kernel for a system call (note: system call not system entry - drivers shouldn't pook about in the u struct 'cause it's probably someone elses). Larry McVoy lm@cottage.wisc.edu or uwvax!mcvoy
djl@mips.UUCP (Dan Levin) (05/13/87)
In article <626@vixie.UUCP>, paul@vixie.UUCP (Paul Vixie Esq) writes: > Mapping the u-area onto 'u.' certainly makes references quicker than using a > structure pointer, since there is one less memory reference before getting to > members of the structure. What I wonder is, how much jumbling is required to > re-map the page, and is the trade-off worth it? Well, since the point of the user area is to contain information not needed unless the process is in core, you have to re-map it when you resume the proc anyway (unless you can share your TLB, and get lucky, and are using your general purpose TLB entries to map the user area). If you have to re-map it, why not always map it to the same virtual addr? In order to avoid a TLB miss on the user struct, we reserve a spot in the TLB for it (since the R2000 TLB is completely under software control, this is done by convention with just a bit of hardware help), and it takes very little time to drop in the new entry ( 9 instructions to be precise, I just looked :-). In answer to the second part, you tend to look in the user struct to find your arguments every time you take a system call (they are loaded there by the entry code), you manipulate the user struct every time you have to lookup an {i|v}node, or do any other of a number of very frequent operations. > Just how much is 'u.' used between context switches, anyway? A whole lot. -- ***dan decwrl!mips!djl mips!djl@decwrl.dec.com
mhl@rust.DEC.COM (Mark Lucovsky) (05/13/87)
The u. vs u-> is really an issue that deals with the location of the kernel stack for the current process. Traditional ports assume that all kernel stacks are based at the same virtual address (inside the u area). If u-> were used then the trick in procdup() where resume is called to arrange for the child process to return through syscall through the same call chain that the parent entered with would become very complicated. Another thing that u. solves is that during a fork, one process enters _syscall, and two processes exit. If u areas were not mapped at the same place then finding the u area for the second process would be tricky. I worked on a system were kernel mode ran unmapped. We were unable to use u. and therefore had to solve some very difficult problems. We even considered copying u areas to a fixed location at every context switch.
jfh@killer.UUCP (John Haugh) (05/15/87)
In article <3568@spool.WISC.EDU>, lm@cottage.WISC.EDU (Larry McVoy) writes: > In article <626@vixie.UUCP> paul@vixie.UUCP (Paul Vixie Esq) writes: > >re-map the page, and is the trade-off worth it? Just how much is 'u.' used > >between context switches, anyway? > > I daresay that it used every single time you enter the kernel for a > system call (note: system call not system entry - drivers shouldn't > pook about in the u struct 'cause it's probably someone elses). > > Larry McVoy lm@cottage.wisc.edu or uwvax!mcvoy I'm not sure this is the best reason for keeping the U page fixed in kernel virtual memory - but it seems to be a _very_ good one. If you get swapped in the middle of a system call, such as a terminal read, when you are swapped back in your U page may reside at a different physical address. On PDP-11's the U page was fixed at 0140000 in Kernel D space. I forget how they convinced the linker to give that address to _u when unix was linked. Also, I don't think it is possible to make _u a pointer to the struct user as you could get swapped after the pointer value was fetched, but before it was used. (Like this) movl _u,r0 ; get address of U page from pointer - interupt - swap out and wait for a while - swap in somewheres else - movl u_error(r0),r0 ; r0 now has wrong address ... I don't know if all of the schedulers are capable of this kind of mess, but it seems that something like this could happen. - John. (jfh@killer.UUCP) Disclaimer - No disclaimer. Whatcha gonna do, sue me?
jfh@killer.UUCP (John Haugh) (05/16/87)
In article <500@rust.DEC.COM>, mhl@rust.DEC.COM (Mark Lucovsky) writes: > > The u. vs u-> is really an issue that deals with the location of the > kernel stack for the current process. Traditional ports assume that all > kernel stacks are based at the same virtual address (inside the u area). [ munch munch ] > I worked on a system were kernel mode ran unmapped. We were unable to > use u. and therefore had to solve some very difficult problems. We even > considered copying u areas to a fixed location at every context switch. This is how it is done in TRS-Xenix so far as I can tell. All 4K of the U-page is copied on each context switch. It is very expensive to say the least, something like 4K * (8 cycles per word + 2 wait states) * 6MHz does not give a whole lot of context switches per second. They seem to get smart and only copy from the base of the U-page to the end of struct user and from the end of the U-page to the SSP. This leaves out all that unneeded stuff in the middle. - john.
henry@utzoo.UUCP (Henry Spencer) (05/20/87)
> I worked on a system were kernel mode ran unmapped. We were unable to > use u. and therefore had to solve some very difficult problems. We even > considered copying u areas to a fixed location at every context switch. Don't laugh, it's been done. I'm told it works okay, if a bit slowly. -- "The average nutritional value Henry Spencer @ U of Toronto Zoology of promises is roughly zero." {allegra,ihnp4,decvax,pyramid}!utzoo!henry
mjl@tropix.UUCP (Mike Lutz) (05/21/87)
In article <8047@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >> I worked on a system were kernel mode ran unmapped. We were unable to >> use u. and therefore had to solve some very difficult problems. We even >> considered copying u areas to a fixed location at every context switch. > >Don't laugh, it's been done. I'm told it works okay, if a bit slowly. When we ported Unix V7 to the old Motorola ExorMacs system, the ublock relocatability problem was the most difficult one we had to face. The ExorMacs MMU only worked in user mode, so the standard technique of using the OS's map in supervisor mode wouldn't cut it. The trickiest part, of course, is handling the system stack for the current process (residing at the top of the UBLOCK). Stacks have lots of addresses in them, many of which cannot be located, making on-the-fly software relocation impossible. We considered the software copy in/copy out to a fixed memory area, but abandoned this as it would have created intolerable interrupt latency. Finally, we resorted to running most of the kernel code in user mode, with software "logical" states mapped onto the hardware "real" states. Overall performance was between that of a PDP11/34 and an 11/45. If you want to know more about the types of shenanigans required, and the issues that arise, look at the paper by Mike Shon and me in the 1983 Toronto USENIX Conference Proceedings. By the way, I believe Motorola's Unix port to the ExorMacs *did* use software copying; I know that in a simple "cc hello.c" benchmark, our version blew them out of the water. Mike Lutz tropix!mjl (no longer an ExorMacs, thank God!)
tim@ism780c.UUCP (05/22/87)
You don't have to worry about getting swapped out like that. A preocess in kernel mode on Unix may only be swapped out when it does not have the CPU, and a process may not lose the CPU to another process unless it wants to ( i.e., calls sleep() or swtch() ). Thus, one does not have to worry about an interrupt causing one to get swapped while in kernel mode. -- Tim Smith "Learn to juggle while it's still legal" sdcrdcf!ism780c!tim
meissner@dg_rtp.UUCP (Michael Meissner) (05/22/87)
In article <8047@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: /* somebody else */ > > I worked on a system were kernel mode ran unmapped. We were unable to > > use u. and therefore had to solve some very difficult problems. We even > > considered copying u areas to a fixed location at every context switch. > > Don't laugh, it's been done. I'm told it works okay, if a bit slowly. Another way to work around this, would be to use the macro processor (cpp): struct ... *u_ptr; #define u (*u_ptr) When the kernel does a context swap, it mearly changes the pointer u_ptr to the new u area. -- Michael Meissner, Data General Uucp: ...mcnc!rti!dg_rtp!meissner It is 11pm, do you know what your sendmail and uucico are doing?