Date: 5 Nov 1998 11:20:45 -0000 From: Ville-Pertti Keinonen <will@iki.fi> To: peter@netplex.com.au Cc: james@westongold.com, current@FreeBSD.ORG Subject: Re: Kernel threading (was Re: Thread Scheduler bug) Message-ID: <19981105112045.668.qmail@ns.oeno.com> In-Reply-To: <199811050902.RAA05396@spinner.netplex.com.au> (message from Peter Wemm on Thu, 05 Nov 1998 17:02:29 %2B0800)
next in thread | previous in thread | raw e-mail | index | archive | help
> Not quite.. Each process could have one page directory for each thread, > up to the number of cpus. If you only have two threads, but 4 cpus, then > you still only need 2 directories. True, I was silently assuming that there are more threads than cpus. It doesn't change the fact that the resource requirements don't seem reasonable. Pages are huge. > We have to do something like this already because of the per-cpu pages in > kernel space. However, the PTD slot is outside the reach of the user > process segment limits so we can't use one of the unused page table page > slots because the address that it corresponds to is outside the user > address space. The existing per-cpu pages might be worth getting rid of. I'm not sure how much data is currently kept there, but the overhead of APIC ID indexing shouldn't be too bad. > The only option would be to take over another PTD slot in reach of user > space, that would cost 256K of virtual address space from the user and > would cost a 4K page for the PTP as well as the data page. 256k? Don't you mean 4MB? I don't think a user address space should contain magic unless it has been explicitly requested by the program. Multithreaded programs are going to have to perform user-space initialization, in any case. Explicitly mmapping special kernel pages might not be out of the question. It still wouldn't be nice to either waste a whole page for a bit of thread-specific data or reveal inconsistent information on the rest of the page. > Hmmmmm.. I wonder.. We might be able to create a GDT slot that maps up > into the per-cpu pages with user priviliges, then have an assembler > routine that (say) loads %fs with the descriptor index, accesses the data > relative to the %fs segment, then restores the %fs register. We could get That's starting to sound like a reasonable idea. Didn't FreeBSD not even save %fs? The kernel could always set it before going into user mode, so that it doesn't need to be loaded for each access. The kernel must either save or set it to make it usable at all. Setting it in the kernel is probably better, to avoid changing things like sigcontext, and if per-cpu pages are not used, things can still work since the kernel can set the register to a cpu-specific segment. IMHO the alternative of using aligned thread stacks is not a bad idea, either. It's fast and portable and it doesn't require anything evil to be done by the kernel. The restrictions placed on what can be done with the threads are a bit nasty, though. 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?19981105112045.668.qmail>