14 ms·

Hmm, interesting. I am wondering about one thing though. > there's simply not a lot of computation involved Wow, 26 instructions. Here's my worst-case scena

• lmm 10y ago
  > Here's my worst-case scenario: you have 8 concurrent threads (a current reality on POWER8), and let's say all of them are engaged in fetching large amounts of data from different servers - let's say disk and TCP I/O are both servers. Speculating: if you were passing all the data in messages, terribly. But that's not how you'd handle it. You'd use messages as a control channel instead, similar to DMA or SIMD instructions. E.g. if you're downloading a file to disk, the browser asks to write a file, the filesystem server does its thing to arrange to have a file and gets a DMA channel from the disk driver server. The TCP layer likewise does its thing and gets a DMA channel from the network card driver, and either the browser or a dedicated bulk-transfer server connects them up. The bulk data should never even hit the processor, yet alone the message-passing routines. > I think it would be genuinely interesting to throw some real-world workloads at Minix, Hurd, etc, and see how they hold up. Do. Also look at QNX which is the big commercial successful microkernel. > Now I'm wondering about ways to preprocess gcc's asm output to add runtime high-resolution function timing information that (eg) just writes elapsed clock ticks to a preallocated memory location (within the kernel)... and then a userspace process to periodically read+flush that area... I'd look at something along the lines of perf_events ( which I encountered via http://techblog.netflix.com/2015/07/java-in-flames.html http://techblog.netflix.com/2015/07/java-in-flames.html ).
  • i336_ 10y ago
    Using messages as a control channel sounds awesome, wow. One of the targets I've been trying to figure out how to hit is how to make message-passing still work if you're using it in the dumbest way possible, eg using the message transport itself to push eg video frames. I'm slowly reaching the conclusion that while it'll work, it'll just be terrible, like you say. I mention this because, at the end of the day, most web developers would just blink at you all like "DM-what?" if you suggested this idea to them. These types of techniques are simply not in widespread use sadly. In my own case, I'm not actually sure myself how you use DMA as a streaming transport. I know that it's a way to write into memory locations, but I don't know how you actually take advantage of it at higher levels - do you use a certain bit as a read-and-flush clock bit? Do you split the DMA banks into chunks and round-robin write into each chunk so that the other side can operate as a "chaser"? I'm not experienced with how this kind of thing is done. Well, workload-testing microkernel OSes is now on my todo list, buried along with "count to infinity twice" :) (I really will try and get to it one day though, it is genuinely interesting) Regarding QNX, I actually mentioned that to the other person who replied in this thread (https://news.ycombinator.com/item?id=13346822 https://news.ycombinator.com/item?id=13346822), and I said a few other words about it a couple months ago - https://news.ycombinator.com/item?id=12777520 https://news.ycombinator.com/item?id=12777520 I really wish the QNX story had gone ever so slightly differently :'( Regarding perf_events and the linked blog post, thanks for both - this is really interesting!
    • lmm 10y ago
      > In my own case, I'm not actually sure myself how you use DMA as a streaming transport. I know that it's a way to write into memory locations, but I don't know how you actually take advantage of it at higher levels - do you use a certain bit as a read-and-flush clock bit? Do you split the DMA banks into chunks and round-robin write into each chunk so that the other side can operate as a "chaser"? I'm not experienced with how this kind of thing is done. I don't know enough to answer this stuff - last message was already second-hand info (or worse). All I can say is, best of luck.