Date: Thu, 4 Nov 1999 23:14:21 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: eischen@vigrid.com (Daniel M. Eischen) Cc: tlambert@primenet.com, julian@whistle.com, freebsd-arch@freebsd.org Subject: Re: Threads goals version III Message-ID: <199911042314.QAA20206@usr07.primenet.com> In-Reply-To: <38220D4B.9BEAFCDB@vigrid.com> from "Daniel M. Eischen" at Nov 4, 99 05:48:43 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > 4) Abuse of kernel threads in order to compete as N kernel > > schedulable entities with respect to other processes in > > the system > > > > This is a dodge to avoid supporting or implementing > > scheduler callses for the class of problems that really > > need scheduler classes, in the hopes that a certain > > unfair competition ratio "will be enough". > > 4a) Use of kernel threads to compete in different scheduler > classes? > > We have a MT application under Solaris with a few threads bound > to LWPs and placed in the real-time scheduler class. These threads > are carefully crafted to not chew up the CPU, but to respond in a > timely manner to events. The rest of the threads in the application > are not in the real-time class (and we don't want them to be) > > I think that what you're implying in 4, is that an application > should place itself in the proper scheduling class/priority to > "achieve unfair competition". My concern is that we not restrict > the kernel scheduling class to be at the process level, but we > allow for fine grained control of the threads within a process. This is an interesting application, however FreeBSD interrupt processing is far from deterministic enough to deal with this issue properly, and moving interrupt processing into kernel threads, which I agree may deal with the SPL issue, will only further damage determinism. One could argue that the program should be using a hybrid scheduling class in the kernel in order to achieve this effect, rather than having to have the idea that you would want to schedule seperate kernel schedulable entities within one program. One of the problems with the Solaris model, overall, is that the term "LWP" is heavily overloaded in Sun-originated literature. For example, in SunOS 4.x, ther was a "liblwp", which was a call conversion user space threads scheduler that did not support SMP scaling or the concept of kernel threads (see the University of Washington paper "User space threads and SPARC Register Windows", from which the original 4.x liblwp implementation was derived). The term I use, KSE (for "Kernel Schedulable Entity"), while more technically correct a description, is also bad, since it has only a little use in the literature. When you say "LWP" in post 4.x Solaris, you're really saying what common usage calls "a kernel thread". This is similarly a bad term, since it implies a whole lot of implementation assuptions that I'm really not prepared to buy into before the goals of "why FreeBSD needs threads" are defined beyond "Linux has them" or "POSIX programmers use them". I would like to see us seperate the idea of threads vs. kernel scheduling. Ideally, there would be very few modifications of the kernel scheduler necessary to support fully threaded, multiple CPU reentrant user space code. The primary ones that I foresee are: o Per CPU run queues o Per process CPU utilization bitmaps (this is possibly a premature optimization, in that it may be acceptable for the process of asking to get on the scheduler queue for additional CPUs could be permitted to be expensive) o A scheduler queue migration facility for gross load balancing over time (statistical, per similar algorithms use in ATM, perhaps). o Seperation of "struct proc" and "struct thread", with the latter primarily being a pointer to the former, a pointer to a kernel stack, a register set, sleep queue context management, a pointer to a user space call completion context, and a linked list by which it could be hung off the proc struct (for things like _exit processing and signals, etc.). Caveat: this is implementation space, and I'd like to get my thoughts into a coherent whole, while allowing others to do the same, so that we can present our ideas around the same time, and the best ideas from everyone's models can make it into the final design. One idea that I would like to _omit_ from the final design is "kernel threads are required for SMP scalability and kernel scheduler differentiation"; it's just not true. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199911042314.QAA20206>