Date: Mon, 02 Nov 1998 15:30:16 +0800 From: Peter Wemm <peter@netplex.com.au> To: "Justin T. Gibbs" <gibbs@narnia.plutotech.com> Cc: current@FreeBSD.ORG Subject: Re: Kernel threading (was Re: Thread Scheduler bug) Message-ID: <199811020730.PAA17256@spinner.netplex.com.au> In-Reply-To: Your message of "Sun, 01 Nov 1998 12:16:00 MST." <199811011916.MAA08880@narnia.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
"Justin T. Gibbs" wrote: > In article <199811011622.AAA25247@spinner.netplex.com.au> you wrote: > > > > You need a kernel stack per thread in the lightweight model, up to a limit > > of the number of cpus running, because it's needed for each possibly > > active thread to make a syscall. > > I don't see how you can achieve such a limited number of stacks > without a thread continuation model. If a thread calls tsleep > while in kernel context, where does it's kernel stack go? If you > always restart the thread from a thread continuation point, you > can throw its stack away. This is certainly very desirable, but > the impact on the kernel would be extremely large. Yes, sorry about that, I managed to confuse myself. I wasn't talking about thread continuation points, that's just too much work. I was more thinking more how the present arrangement of having the PCB, signal vectors, and pstats and kstack co-habitating the same pages would have to be revisited and that only a maximum of numcpu kstacks would be in memory at once. The hassle is the signal vectors etc would be per process, some of the pstats per thread, the rest per process, the pcb per thread, kstack per thread, etc. Trying to seperate it all out, keeping track of what goes where, while still perserving the ability to swap out the process and all it's stacks, upages, etc to keep the unswappable per-thread and per-process state to a minimum. The way to do this is probably to take the UPAGES out of kvm managed space and have a chunk of address space (next to the per-cpu pages perhaps) at a fixed address that holds swappable process state, all the kstacks wired in as needed etc. Doing swapping would be pretty easy then, and all this would be machdep parts right next to the existing UPAGES swap support. It would probably be worthwhile having idle thread kstack pages individually pageable, as well as 'swap the whole damn lot out'. Going down this path would probably require some sort of 'max kthreads per process' limit to enable address space layout. Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199811020730.PAA17256>