On 17/03/14 09:07, Martin Unzner wrote:
>> So, yes, rump_sys_sendto() is designed to be a
>> drop-in-replacement-with-no-strings-attached for sendto() -- at least
>> assuming you have the corresponding socket opened ;). Calling
>> rump_sys_sendto() will be significantly faster if you have curlwp set
>> (what I call a "bound" thread), but it will work correctly either way.
> OK, so it would probably not be bad to do something like this in netperf
> (from your thesis):
>
> rump_pub_lwproc_rfork(RUMP_RFCFDG);
> rump_schedule();
> for(...) {
> rump_sys_sendto(...);
> }
> rump_unschedule();
>
> If I got it right, rump_pub_lwproc_rfork does not perform a fork
> operation in the host program, but only in the Rump kernel? Do I need to
> make sure that there are no non-Rump operations before
> rump_unschedule(), and if so, why? For instance, in your thesis you have:
Yes, calling rfork is desirable since it creates a bound thread and will
allow your call to take the fastpath in the scheduler.
No, the rump_schedule() is not needed (or even allowed).
rump_schedule() is already called by rump_sys_sendto(). Think of it
this way: rump_schedule() + rump_unschedule() are used to lock a
resource. Calling mutex_lock() twice without a mutex_unlock() in
between is illegal, and so is calling rump_schedule() twice. In fact,
analogy with mutexes goes even further: rump_schedule() reserves the
resource only the for the calling thread. So if you want to call the
rump kernel from multiple threads, each thread needs their own
schedule/unschedule dances.
I'm not sure what "no non-Rump operations" means.
I'd also recommend you to re-read section 2.3 in the blue book. It will
hopefully make a whole different kind of sense after working with the
relevant concepts on the implementation level. (I'll be the first to
admit that it's not very easy to read without prior "hands-on" experience)
> if (mylwp->l_dupfd < 0) {
> rump_unschedule();
> errx(1, "open failed");
> }
>
> If you are exiting anyway, would rump_sys_reboot() work instead of
> rump_unschedule?
Generally speaking, a test program can give a much more reliable answer
than any human on this list. After that is done, humans will be more
efficient in figuring out why or why not.
> And another question rather basic question: Is there a prominent use
> case where I would need multiple lwps in Rump?
Due to how NetBSD uses kernel threads, quite a few lwps exist right
after calling rump_init(). I guess that's a fairly prominent use case ;)
Apart from that, what Justin said, though I'd say "concurrent
operations" instead of "blocking operations" (and they may even be
parallel operations).
> Thanks!
>
> Martin
>
> [1] https://mail-index.netbsd.org/netbsd-users/2011/10/09/msg009340.html
citation not referenced from text?
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
rumpkernel-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/rumpkernel-users
