Eh... Now, why is this moded as interesing? This story was not about problems installing Linux on the said laptops. This story was about installing FreeBSD on them. I'm sure Linux works fine on the laptops. I'm sure Windows works fine on them. I'm sure FreeBSD works fine on the laptops which are not affected (I mean, I run FreeBSD on a ThinkPad 600e right now). Anyway, this is not the point is it? Please read the actual story before complaining about uninformed story-posters.
Compaq has also been doing a load of nice work on value profiling. There has been a few publications lately describing their DCPI (Digital Continous Profiling Infrastructure).
It's kind of cool; they actualy sample executing code (including kernel) at regular intervals by interpreting some instructions from the instruction stream instead of just recording the instruction pointer. This enables them to gather statistics about the outcome of instructions, physical location of load/store instructions, whether the instruction hit in the cache, how long it took to execute the instruction, and so on.
There is supposedly a downloadable evaluation version of the software at their website (problem of course, is that it only works on alphas running Tru64 Unix or Windows NT).
Well, if one of the key components are failing in the system, you will have a pretty hard time to recover from the problem. If, for instance, the disk driver or file system does not work, you might not be able to restart the servivce (since the servers resides on disk). If all ``non-system'' tasks are controlled by a scheduler task, you will have a hard time to get a terminal window scheduled so that you can restart the service. If you your keyboard driver driver fails, there's not much help of typing anything. The list goes on...
It is true, however, that not all os components behave this way. Some components may indeed be restartable. It's just a matter of how inconvient such a restart is for the user (e.g., restarting the network server will require that all open network connections are closed). Of course, some components can be constructed in such a way that they are completely stateless with regard to other components/tasks in the system, but I do not believe that this is the general case.
BTW, for more info on componentized operating systems (and componentized Linux in particular), take a look at the SawMill Project homepage.
Plus there is work on doing it for PowerPC and also plans for upcoming 64 bit architectures like IA-64. A fairly new member of the L4 kernel family, the L4Ka kernel is actually quite portable. Doing ports to other architerures is as such not a big of a hurdle as it used to be.
A bit of clarification here. It is not entirely true that nothing really happens when a kernel service goes berserk. If for instance, the virtual file system service, a device driver, a scheduler service, a memory management service, or the like goes berserk, it is pretty much nothing that you can do apart from rebooting the machine. There are far too many interdependncies between the different service components, and mostly all of them have to trust each other in one way or another.
On the other hand, if one of your services does go berserk, having a microkernel design usually helps you a great deal in localizing where things went wrong.
By core service i pressume that you here mean a service that is offered by the microkernel. Now, if you build a monolithic system on top of a microkernel (i.e., an opereating system kernel running as a single task in user-mode -- usually called an OS personality), this task will be able to perform most of the responsibilities that a normal os kernel does -- without using any of the core services. This is possible because the os kernel (running as a task) has exclusive acccess to any of the hardware resouces it needs (e.g., devices), and is the approach taken by L4Linux (running on top of L4) and MkLinux (running on top of Mach).
Of course, in a real system you also have other tasks which needs to interact with the OS task. This occurs (almost) exclusively through IPC mechanisms, and IPC mechanisms have therefore been identified as the main performance bottleneck for microkernel systems. The IPC mechanism basically deals with transferring (usually a small) amount of words from one task/thread to another, and performing a context switch between the tasks/threads. There are three sides to the cost associated with this:
The added number of processor cycles used to actually perform the context switch.
The added number of flushed cache lines due to the microkernel design.
The added number of TLB invalidations/flushes.
The first cost can only be dealt with by producing higly optimized microkernel code. (Just for the numbers, last time I measured the inter task IPC cost in the L4 microkernel on a 500MHz PIII, it was 197 processor cycles. For slower processors, the cost of IPC is even cheaper). The second cost can be alleviated by making the cache footpring for the microkernel as small as possible. For instance, the L4 microkernel accesses 12 cache lines for its typical IPC operation. The third cost can be dealt with by not using much memory for the microkernel itself, and using tagged TLBs so that a TLB need not be flushed completely on each context switch. Now, of course, not all architecures, and in particular not the x86, do have tagged TLBs. Fortunately, however, tagged TLBs can be simulated by the microkernel (see this paper for more info).
Hehe. Showing a screenshot of,e.g., a Linux server running on top of L4 doesn't seem to impress to many people. That's one of the problems we usually have to face when we demonstrating what we do to non-insiders. And, by the way, the ``most official'' L4 site is now located on the L4Ka website.
Using a directory structure to navigate non-hierarchical data just isn't the way to go. MP3s were designed with that in mind, but no one's been paying attention. Use a little DB to organize this, please.
Or even better: use both. Having a dircetory structure is very convenient when browsing through your files outside of your MP3 player.
Not entirely true. The FreeBSD book does not go into any details concerning, e.g., the internals of the kernl. That is, you do not have any books like ``Linux Kernel Internals'' or ``Linux Device Drivers'' for FreeBSD. This is useful for people who wants to play around inside FreeBSD, and also for teaching purposes. Here at my university (at least in the group that I'm working in), we organize seminars with undergrad students doing case studies of specific platforms. Since we are doing (operating) systems research, we tend to do these undergrad seminars on operating system internals. Problem, of course, is that we tend to have a hard time finding good books on the subjects (except for Linux). The thing that comes closest to what I am really looking for in BSD is the BluePrints section in Daemon News.
Microkernel technology is hard to sell. Despite this fact though, people are still developing new -kernels and doing active research in the area. BeOS has been mentioned as one example. Pebble from Bell Labs is another. One would hardly call the technology a relic of the past.
As for the performance degradation that the -kernel architecture imposes on the system, there has been quite a lot of research in the last ten years indicating that this effect can be alleviated. Moreover, much of the performance degradation due to the added number of context switches in -kernel systems is due to inneficient/inapropriate hardware mechanisms and design. By harnessing state of the art hardware design (e.g., IA-64), we may come to see that the added overhead of context switches is ignorable. There is work underway to create efficient -kernels for these more arcane architectures, and only time will tell whether our hopes can be reached or not.
Also, -kernel technology is believed to pose a compelling soultion to the one-size-fits-all problem that you address in conjunction with Linux. To put it short, one would compile the operating system components so that they match the exact requirements that you meet in, e.g., pervasive computing or big irons. In fact, IBM is doing joint research with a number of universities aiming at providing a multiserver version of Linux - SawMill Linux - with these exact goals in mind. This work may of course fail (that's the beauty of research), but I think it is a bit early yet to put the last nail in the coffin for multiserver operating systems.
And just for the records: SawMill is hopefully going GPL any time soon now, enabling people to use it with the GPLed Fiasco or newly developed L4Ka -kernels. (That should probably make you GPL zealots happy.;-)
Re:Code Forks/What have the Romans ever done for u
on
HURD For 'Big Iron'?
·
· Score: 1
"There are the L4Linux, L4KALinux and MkLinux microkernels."
Well, there is actually no such thing as L4KaLinux. There is L4Ka though, which is another implementation of the L4 -kernel, and which is able to host the L4Linux kernel (leaves you with one less code fork;-).
Well, I recently attended a very interesting/entertaining speach by Bill Pulleyblank, director of the IBM Deep Computing Institute. He presented their research on the Blue Gene computer, a beast aiming at Petaflop (that's one million gigaflops!) performance. The main application for the computer was that of simulating protein folding.
Pullybank also talked about deep computing in general, and mentioned several applications, none of which involved nuclear simulations. So, not everyone has nuclear bomb simulations in mind when building supercomputers.
Slashdot Mirror
The funny thing is that people (in particular Linux zealots) probably believe in this.
Eh... Now, why is this moded as interesing? This story was not about problems installing Linux on the said laptops. This story was about installing FreeBSD on them. I'm sure Linux works fine on the laptops. I'm sure Windows works fine on them. I'm sure FreeBSD works fine on the laptops which are not affected (I mean, I run FreeBSD on a ThinkPad 600e right now). Anyway, this is not the point is it? Please read the actual story before complaining about uninformed story-posters.
It's kind of cool; they actualy sample executing code (including kernel) at regular intervals by interpreting some instructions from the instruction stream instead of just recording the instruction pointer. This enables them to gather statistics about the outcome of instructions, physical location of load/store instructions, whether the instruction hit in the cache, how long it took to execute the instruction, and so on.
There is supposedly a downloadable evaluation version of the software at their website (problem of course, is that it only works on alphas running Tru64 Unix or Windows NT).
It is true, however, that not all os components behave this way. Some components may indeed be restartable. It's just a matter of how inconvient such a restart is for the user (e.g., restarting the network server will require that all open network connections are closed). Of course, some components can be constructed in such a way that they are completely stateless with regard to other components/tasks in the system, but I do not believe that this is the general case.
BTW, for more info on componentized operating systems (and componentized Linux in particular), take a look at the SawMill Project homepage.
Plus there is work on doing it for PowerPC and also plans for upcoming 64 bit architectures like IA-64. A fairly new member of the L4 kernel family, the L4Ka kernel is actually quite portable. Doing ports to other architerures is as such not a big of a hurdle as it used to be.
On the other hand, if one of your services does go berserk, having a microkernel design usually helps you a great deal in localizing where things went wrong.
Of course, in a real system you also have other tasks which needs to interact with the OS task. This occurs (almost) exclusively through IPC mechanisms, and IPC mechanisms have therefore been identified as the main performance bottleneck for microkernel systems. The IPC mechanism basically deals with transferring (usually a small) amount of words from one task/thread to another, and performing a context switch between the tasks/threads. There are three sides to the cost associated with this:
- The added number of processor cycles used to actually perform the context switch.
- The added number of flushed cache lines due to the microkernel design.
- The added number of TLB invalidations/flushes.
The first cost can only be dealt with by producing higly optimized microkernel code. (Just for the numbers, last time I measured the inter task IPC cost in the L4 microkernel on a 500MHz PIII, it was 197 processor cycles. For slower processors, the cost of IPC is even cheaper). The second cost can be alleviated by making the cache footpring for the microkernel as small as possible. For instance, the L4 microkernel accesses 12 cache lines for its typical IPC operation. The third cost can be dealt with by not using much memory for the microkernel itself, and using tagged TLBs so that a TLB need not be flushed completely on each context switch. Now, of course, not all architecures, and in particular not the x86, do have tagged TLBs. Fortunately, however, tagged TLBs can be simulated by the microkernel (see this paper for more info).Hehe. Showing a screenshot of,e.g., a Linux server running on top of L4 doesn't seem to impress to many people. That's one of the problems we usually have to face when we demonstrating what we do to non-insiders. And, by the way, the ``most official'' L4 site is now located on the L4Ka website.
Or even better: use both. Having a dircetory structure is very convenient when browsing through your files outside of your MP3 player.
Not entirely true. The FreeBSD book does not go into any details concerning, e.g., the internals of the kernl. That is, you do not have any books like ``Linux Kernel Internals'' or ``Linux Device Drivers'' for FreeBSD. This is useful for people who wants to play around inside FreeBSD, and also for teaching purposes. Here at my university (at least in the group that I'm working in), we organize seminars with undergrad students doing case studies of specific platforms. Since we are doing (operating) systems research, we tend to do these undergrad seminars on operating system internals. Problem, of course, is that we tend to have a hard time finding good books on the subjects (except for Linux). The thing that comes closest to what I am really looking for in BSD is the BluePrints section in Daemon News.
As for the performance degradation that the -kernel architecture imposes on the system, there has been quite a lot of research in the last ten years indicating that this effect can be alleviated. Moreover, much of the performance degradation due to the added number of context switches in -kernel systems is due to inneficient/inapropriate hardware mechanisms and design. By harnessing state of the art hardware design (e.g., IA-64), we may come to see that the added overhead of context switches is ignorable. There is work underway to create efficient -kernels for these more arcane architectures, and only time will tell whether our hopes can be reached or not.
Also, -kernel technology is believed to pose a compelling soultion to the one-size-fits-all problem that you address in conjunction with Linux. To put it short, one would compile the operating system components so that they match the exact requirements that you meet in, e.g., pervasive computing or big irons. In fact, IBM is doing joint research with a number of universities aiming at providing a multiserver version of Linux - SawMill Linux - with these exact goals in mind. This work may of course fail (that's the beauty of research), but I think it is a bit early yet to put the last nail in the coffin for multiserver operating systems.
And just for the records: SawMill is hopefully going GPL any time soon now, enabling people to use it with the GPLed Fiasco or newly developed L4Ka -kernels. (That should probably make you GPL zealots happy. ;-)
Well, there is actually no such thing as L4KaLinux. There is L4Ka though, which is another implementation of the L4 -kernel, and which is able to host the L4Linux kernel (leaves you with one less code fork ;-).
Just to quote from the features section of openpackages.org:
Pullybank also talked about deep computing in general, and mentioned several applications, none of which involved nuclear simulations. So, not everyone has nuclear bomb simulations in mind when building supercomputers.