Date: Thu, 05 Nov 1998 17:02:29 +0800 From: Peter Wemm <peter@netplex.com.au> To: Ville-Pertti Keinonen <will@iki.fi> Cc: James Mansion <james@westongold.com>, current@FreeBSD.ORG Subject: Re: Kernel threading (was Re: Thread Scheduler bug) Message-ID: <199811050902.RAA05396@spinner.netplex.com.au> In-Reply-To: Your message of "05 Nov 1998 09:39:06 %2B0200." <8667cud1wl.fsf@not.oeno.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Ville-Pertti Keinonen wrote: [..] > As a "fix", each process could have as many page directories as there > are CPUs, but creating them "on-the-fly" each time would be too slow > and letting them exist while not running the process could end up > costing two pages per extra cpu per multithreaded process in addition > to the actual thread-specific pages. It doesn't scale well. 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. 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 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. 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 16 bytes of Thread Local Storage very cheaply which would not require traps, kernel entry, etc to get access to. Cheers, -Peter -- Peter Wemm <peter@netplex.com.au> Netplex Consulting "No coffee, No workee!" :-) 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?199811050902.RAA05396>