On Jul 2, 2014 11:02 AM, "Antti Kantee" <[email protected]> wrote:
>
> On 01/07/14 21:01, Justin Cormack wrote:
> > In case anyone is interested, here is my rough TODO list for
> > rumpfiber... comments welcome.
>
> Put it on the wiki under "project ideas"?
>
> I'm still not sure where you're going with rumpfiber. Is it supposed to
> be the prototype baremetal implementation or a userspace implementation
> with special characteristics.
Both. See the original rationale. That does make it a bit odd if it was
just for bare metal would just take a lot out...
> quick comments:
>
> > 2. Split out into modules
> > Started this, eg splitting out rumpuser_file.c as user may want to
> > modify, replace or not include at all. Most of these are just the
> > original ones (eg dl, which an embedded system wont want), but maybe
> > inclined to split out memory allocation, random numbers and so on as
> > these may vary.
>
> For all such rototills, where it makes sense, I hope you perform the
> same for librumpuser. At least currently, I still think it would be
> fairly easy to compile both out of the same codebase with a toggle: one
> uses pthreads, one uses swapcontext. Unless, of course, you're going in
> a different direction than what I'm guessing ;)
They shouldn't diverge.
There is the repo question. I could merge original rumpuser in and work on
both or merge rumpfiber into NetBSD or...
> > 4. Some way of cleanly integrating _lwp handling
> > This means sorting out NetBSD env for building and access to internals
> > in a clean way.
>
> Not internals, since _lwp is an exported interface, but regular
> userspace headers. It will probably be solved as part of the revamp
> discussed in the "rethinking buildrump.sh" thread.
I meant that it needs access to scheduler internals. The userspace headers
are not a problem.
> > 7. Less locking
> > I think Antti was suggetsing that something even more optimised than
> > locks_up.c possible without concurrent threads.
>
> It doesn't affect the rumpfiber side, only atomic ops: if we assume that
> all threads accessing rump kernels run use fibers, we don't need atomic
> ops even in scheduler.c. That's, what, 3 atomic ops total. Not really
> sure if it's going to be measurably better than what you can do with
> RUMP_LOCKS_UP.
>
> Notably, currently a RUMP_LOCKS_UP build will use real atomic ops
> everywhere. The first step would be to make that build use
> pseudo-atomic ops, i.e. ones where semantics are maintained without
> "lock" instructions.
The uncontended cases should be fast in theory so it is probably a minimal
win but may still be worthwhile.
> > 9. Block and network backends
> > Both of these currently rely on pthreads. The aio block code should
> > work, if its read thread is replaced by polling in the scheduler.
> > Probably want a scheduler hook for a simple poll and one for poll()
> > instead of sleeping when idle.
> >
> > 10. rump_server
> > This should I think now work, bar the etfs stuff which needs 9, so
> > just needs a build script.
>
> etfs doesn't use bio, it just executes read/write calls in the caller
> context. bio could do the same as an easy first stab.
Ah OK. It should just work then...
> networking is a bit more interesting. I assume you could do a poll-loop
> with netmap. However, given that you probably want periodic polling for
> the high-throughput cases to take advantage of batching, a simple sleep
> loop might be appropriate (that's what dpdk-rumptcpip currently does
> anyway).
It may depend on the back end so a few hooks probably needed.
>
------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community
Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________
> rumpkernel-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/rumpkernel-users
------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
rumpkernel-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/rumpkernel-users
