On Tue, 30 Nov 1999, Chuck Robey wrote:

My take on this is as follows: The UTS has some sort of structure that is private to itself. it also has a descriptor for each thread, and each thread has a stack on which there is some saved context.

The kernel needs to know that when the UTS is blocking it should NOT perform an upcall. The result of this is that yes, the UTS actually blocks. However this should only happen at startup because the UTS will be hot code and data. The kernle knows it's the UTS because it knows where the UTS's stack is and cna check whether the blocking thread is on that stack. Other time s that the UTS might block in a pagefault are when loading context from the incoming thread's stack (it may have been paged out.) and when reading the structure describing that thread.

In the first case, the UTS is about to relinquish control of the processor to the incomng thread, so we can move it's stack pointer to a location within the new stack already. This nesures that it will not be recognised as being the UTS and some other thread will be given the oportunity to run while the page is being brought in. The second is a bit more difficult, because the UTS may need to read this structure while doing more mundane tasks, (e,g figuring out who to run). However this structure is quite a bit smaller. it is possible that the page on which it sits will alway be in core as somewhere else on it is a thread that get's called more often. Still we need to keep this page resident. It is possible that we may be able to do some mmapp or sysvSHM trick to keep this small region in core. Failing this we may just need to block. I'm not sure that a goal of teh thread system is to have the programs NEVER EVER EVER block. What iof the whole program is swapped out at a busy time?

What we can do however is make it pretty dammed unlikely, by keeping these structures small and in hot pages.

Julian

To Unsubscribe: send mail to majo...@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message