Date: 6 Nov 1998 12:44:58 -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: <19981106124458.13542.qmail@ns.oeno.com> In-Reply-To: <199811051428.WAA06376@spinner.netplex.com.au> (message from Peter Wemm on Thu, 05 Nov 1998 22:28:46 %2B0800)
next in thread | previous in thread | raw e-mail | index | archive | help
> We've done it that way before and it was a real pain in the backside. There > are a number of disincentives: > - apic id's are all over the place. 0, 12 and 13 are common with P6's. > Having 16 slots in arrays for all the per-cpu variables is not nice. You only need one per-cpu structure for the variables and one array of slots that point to those structures. > - converting things from variables to macros shows up other things. I > seem to recall some places where "curproc" was referenced over and > over again in loops and the like. Don't do that, then. > - we have to have different binaries modules/lkm's for SMP and non-smp > kernels. Unless you change the way the kernel works without SMP. I think the current SMP code goes too far in ensuring that a non-SMP kernel isn't affected. You can't continue that way indefinitely, certainly not if you want kernel threads. > - accessing the local apic is *much* slower than a memory access (according > to one of the intel people who told us to try and do it this way if we > could). Kernel stacks certainly have a fixed size, are they also aligned? ;--) > - it was a lot of pain to get working in the first place. That's natural when you do something like SMP in a system that wasn't designed for it. You can't expect the remaining stuff to be painless, either. Locking is still supposed to become finer-grained eventually, right? ;--) > rfork() could "set" %fs for the child to tell it what slot to use. If it > wished to leave %fs untouched, it could use it at any time. Otherwise it > would have to store it somewhere. It would be the same value for all > processes on the system. Having a single segment still assumes cpu-specific page directories. Of course they aren't *that* expensive. > The bit that I don't like about it is that it forces all the stacks to have > the same upper limit size. That could be a bit wasteful of address space, > or could leave you short on room to grow the stack. Incidently, I'd like a > special mmap() option to provide a real grow-down stack in a specified > region. mmap()ing a few hundred kb of stack from anonymous swap times a > few hundred threads adds up on the size counter. I think multithreaded programs should be quite conservative in terms of stack usage. Reasonably-written programs that don't allocate buffers at several nesting levels on the stack shouldn't typically use more than a couple of kB of stack. I haven't looked at what the actual case is in the real world, multithreaded programs still aren't common (most of them are commercial). On the Amiga, 4k was how much stack you allocated for somewhat stack-hungry programs...until programs ported from Unix came along... Multithreaded programs can't generally expect to allocate huge amounts of stack the way many traditional programs (such as GNU C) do. Even with variable stack sizes, a stack-hungry program is probably going to have several stack-hungry threads. But yes, there are lots of other problems, including the fact that setting the stack size limit using the POSIX thread API becomes difficult... > Also, while on the subject, something Julian said has got me thinking about > creating kernel threads on the fly when and if a user thread happens to > block. This sounds rather interesting.. - async IO is done this way too I That sounds like the opposite of what I did in bpmk (where kernel threads are detached from user threads when they block on message passing -- of course the kernel knows about both kernel and user threads, "kernel" threads just mean runnable threads). > think. It would require a fair amount of cooperation between the thread > "engine" and the kernel, perhaps by having an executive thread of sorts > that handled the kernel interation and thread activation. That could be good. 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?19981106124458.13542.qmail>