Antti,
> We did all of this to demonstrate a scheduling technology that is likely of >> less interest here. The performance of the system is roughly on-par with >> Xen for nginx serving persistent connections even with a pretty brain-dead >> data-movement mechanism that requires quite a bit of memcpy. >> > > In the spirit of "one must learn everything to know just a little bit", > I'm personally interested in at least a short summary on your scheduling > technology. Furthermore, since the claim is that rump kernels are > scheduler-agnostic (which is really what separates them for everything > else), your work offers anecdotal proof, so I think at least some further > details are of general interest to this list. Links to papers on your > scheduler are of course also welcome, if you can share any currently. We have an annoying academic academic problem that our paper is currently under (blind) review, so I don't want to publicly associate ourselves with the tech in this forum. That would be an annoying reason to get the paper rejected without review. I'll send a personal email. > The interest depends on if your work can be seen to be useful outside of > Composite, what sort of maintenance burden it adds, etc. So, please post > details. Per the very least, like I [think I] said earlier, if you want to > propose hooks to "document" where your code attaches, those can usually be > added with relatively little pain. > We're going to clean up the code for a while, and we'll keep our eyes out for the additional rumpuser calls and other hooks we added. > Also, please make use of the wiki to link back to your work. There's the > obvious "publications" page: > http://wiki.rumpkernel.org/Info%3A-Publications-and-Talks If it accepted, we'll post it here. > There's also the "who uses rump kernels" page, which I created a while ago > but forgot to advertise: > http://wiki.rumpkernel.org/Info%3A-Who-Uses-Rump-Kernels Added. Best, Gabe
