Linked by Thom Holwerda on Fri 25th Sep 2009 23:12 UTC, submitted by Still Lynn
Microsoft Most of us are probably aware of Singularity, a research operating system out of Microsoft Research which explored a number of new ideas, which is available as open source software. Singularity isn't the only research OS out of Microsoft; they recently released the first snapshot of a new operating system, called Barrelfish. It introduces the concept of the multikernel, which treats a multicore system as a network of independent cores, using ideas from distributed systems.
Thread beginning with comment 386462
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: Comment by kaiwai
by kjmph on Sat 26th Sep 2009 22:42 UTC in reply to "Comment by kaiwai"
kjmph
Member since:
2009-07-17

Yes, good points. I would presume that this model would only take down applications that were currently running on the failed core. However, you would have to deal with messages in flight to the running core, so there would be unknown state to clean up. I bet you could easily cycle/reset the core into a known state. So, greater up-time in the long run.

As far as overhead is concerned, they say that native IPC was 420 cycles and the similar message passing implementation cost 757 cycles. That's 151ns vs 270ns on the 2.8GHz chips they were testing on. However, by breaking the current synchronous approach and using a user RPC mechanism they dropped the message passing to 450cycles on die, and 532cycles one hop. With two hops only costing tens of cycles more. Which is really starting to become negligible. So, it does cost, but where they excelled was multi-core shared memory updates. But, to get back to your comments, that really is not general purpose computing as of today, as most applications on my Linux box are single threaded. Of the few apps that aren't single threaded, ffmpeg and Id's Doom3 engine, they are most likely aren't synchronizing shared memory updates, rather I think they would isolate memory access to certain threads and pass commands around via a dispatcher thread. So, this is a pretty specific type of applications that excel on Barrelfish. I think they are targeting Google's MapReduce and Microsoft's Dryad.

Finally, it's important to notice that HW is moving to a message passing type architecture as well. AMD had implemented HyperTransport and Intel now has the QuickPath Interconnect. So, in Barrelfish, the implementation of the message passing on AMD's cpus is based on cache lines being routed via HT. In other words, hardware accelerated message passing. They isolated the transport mechanism from the message passing API, so I believe they could swap in different accelerated transport implementations depending on the architecture it's currently running on.

Reply Parent Score: 2

RE[2]: Comment by kaiwai
by kaiwai on Sun 27th Sep 2009 04:45 in reply to "RE: Comment by kaiwai"
kaiwai Member since:
2005-07-06

Yes, good points. I would presume that this model would only take down applications that were currently running on the failed core. However, you would have to deal with messages in flight to the running core, so there would be unknown state to clean up. I bet you could easily cycle/reset the core into a known state. So, greater up-time in the long run.


I'd assume with the multiple kernels there would be a thin virtualisation layer sitting on top which makes the 'cluster' of kernels appear as a single image with the same sort of result when a single machine goes off line there is maybe a momentary stall as either there is a retry of the processing or issuing a failure notice to the end users - the preferable scenario being the former rather than the later.

As far as overhead is concerned, they say that native IPC was 420 cycles and the similar message passing implementation cost 757 cycles. That's 151ns vs 270ns on the 2.8GHz chips they were testing on. However, by breaking the current synchronous approach and using a user RPC mechanism they dropped the message passing to 450cycles on die, and 532cycles one hop. With two hops only costing tens of cycles more. Which is really starting to become negligible. So, it does cost, but where they excelled was multi-core shared memory updates. But, to get back to your comments, that really is not general purpose computing as of today, as most applications on my Linux box are single threaded. Of the few apps that aren't single threaded, ffmpeg and Id's Doom3 engine, they are most likely aren't synchronizing shared memory updates, rather I think they would isolate memory access to certain threads and pass commands around via a dispatcher thread. So, this is a pretty specific type of applications that excel on Barrelfish. I think they are targeting Google's MapReduce and Microsoft's Dryad.

Finally, it's important to notice that HW is moving to a message passing type architecture as well. AMD had implemented HyperTransport and Intel now has the QuickPath Interconnect. So, in Barrelfish, the implementation of the message passing on AMD's cpus is based on cache lines being routed via HT. In other words, hardware accelerated message passing. They isolated the transport mechanism from the message passing API, so I believe they could swap in different accelerated transport implementations depending on the architecture it's currently running on.


Well, it is the same argument I remember having about Micro-kernels and the apparent slowness. Although every desires the absolute maximum performance I would sooner sacrifice some speed and have slightly more overhead if the net result is a more stable and secure operating system. Internet Explorer 8 for example has a higher over head because of process isolation and separation but it is a very small price to pay if the net result is a more stable and secure piece of software.

It therefore concerns me when I hear on osnews.com the number of people who decry an increase in specifications off the back of improved security and stability (with a slight performance penalty). Hopefully if such an idea were to get off the ground there wouldn't be a similar backlash because the last thing I want to see is yet another technology that comes in half baked simply to keep the ricers happy that their system is 'teh max speed'. They did it with Windows when moving the whole graphics layer into the kernel, I hope that the same compromise isn't made when it comes to delivering this idea to the real world.

Reply Parent Score: 2