Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU |
On 07/13/2010 10:28 AM, Edward Ned Harvey wrote: >> From: discuss-bounces-mNDKBlG2WHs at public.gmane.org [mailto:discuss-bounces-mNDKBlG2WHs at public.gmane.org] On >> Behalf Of Mark Woodward >> >> Maybe its an OS issue? Like the RAID process described above, operating >> systems have to become far more modular and parallel to benefit. >> > You mean more modular and parallel than what? They already support SMP (for > years since) and virtualization and hyperthreading... How do you mean more > modular? > This is a complex discussion, to keep it simple I will use several vague generalities, so understand that I know there are threads used by the Linux kernel and there are no true absolutes here. That said, the problem with monolithic kernel design is that they are designed primarily and conceptually as an API library for applications. An application execs a kernel call, the function jumps into kernel code, executes the API code, and returns a value. In the multiple processor paradigm, a task will place its request in a message queue which will be read by a user space process, that process will execute the code, and place the result in the message. On a highly parallel system multiple CPUs/threads will be executing. While there is more work in the second example, the overall throughput of the second example will be higher in a highly parallel system. > > >> That >> whole user-space micro-kernel process stuff doesn't sound so useless >> now. Monolithic/Modular kernels ruled as CPU cores were scarce. >> > They still rule now. Is there some alternative that doesn't use a > monolithic or modular kernel? I don't know of any other option... > The point I'm making is that monolithic kernels will not perform as well as micro-kernel designs when there are many many CPUs. >> With >> many multiple CPUs, there is actually REAL benefit that can be taken >> from it. Also, old truisms may now becoming wrong. A user space process >> for handling services should now be effectively more efficient (in >> operation) than kernel based ones as long as resource access and >> contention are managed well. >> > Now this one, I am completely missing. How on earth can anything in user > space be *more* efficient than in kernel space? > > I could see it, if you were saying "just as efficient" ... but "more" > efficient? > The phrase you missed is "effectively more efficient." Meaning, yes you are right it won't be as purely efficient, however, in practice, by parallelizing the work, we may lose, lets say something bad, 50% efficiency over a single kernel API, but by spreading the work across multiple abundant CPUs and decoupling the work from the client thread, we could substantially increase the throughput of the system.
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |