On Sun, Jun 22, 2014 at 11:47 PM, Antti Kantee <[email protected]> wrote: > On 22/06/14 22:25, Justin Cormack wrote: >> Ok, my swapcontext based hypercall library seems to be working now... >> >> https://github.com/justincormack/rumpfiber >> >> The basic idea is it does not use pthreads, but uses cooperative >> userspace threads using the widely available getcontext/swapcontext >> calls which create multiple stacks within a single OS thread. > > Awesome to see this come to life. I remember brainstorming about it > with you at FOSDEM in February.
indeed... >> 1. For embedded systems that do not have a thread library and are single core >> 2. If you are running eg one network stack per core so threading is >> not going to help >> 3. To cut down on amount of time spent on locks, as these become trivial. > > Hmm, so if we use librumpfiber and a rumprun stack, we don't need > locks_up.c and we can remove _all_ atomic ops (including the ones in the > scheduler, which are required with locks_up.c). > > .. at least unless I'm missing something. That's a nice result, makes > "virtually uniprocessor" even more special. Yes I think thats right, its a more complete version of what locks_up was trying to do. >> Why not? >> 1. No parallelism. The NetBSD network stack is being made much for >> multi processor friendly, so you might lose performance. > > I still think that if you can partition the network correctly, running n > networking stacks on 1 core each is faster than 1 stack on n cores. Yes I think so, with modern hardware you can create virtual network devices or queues on demand, with the expected model being one per core to avoid lock contention anyway, so this fits very well. >> 2. Some stuff missing - I deleted eg the block device driver as it was >> using threads, daemonize support etc. These are intended to be put >> back, they just need some thought and were optional so were >> temporarily removed. > > For bio you can just delete half and run everything in the caller's > context. It won't be efficient, but it'll at least work. > (not that the bio stuff still is very efficient even with threads) It is probably worth integrating polling of io into the (currently very dumb) scheduler. >> 3. Needs some namespacing cleanup. (not even sure if lib should be >> called librumpuser as well). > > I'm 50/60 about that. I can think of good arguments to use that name, > and likewise to not use that name. Yes,its much easier to run ljsyscall if the name doesnt change. >> 4. build process too simple and no fun, just type make. Clearly needs >> more options. > > nobody's perfect ------------------------------------------------------------------------------ HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems _______________________________________________ rumpkernel-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rumpkernel-users
