Re: [osv-dev] how to monitor OSv's system indicators？

['Dor Laor' via OSv Development]

The easiest is through the host, with KVM, it's just a regular process and
you can use
all standard Linux tools to track it. There are also detailed monitoring
data (forgot where but it's documented)

On Wed, Mar 20, 2024 at 9:49 AM one and  wrote:

> Hello, I have successfully run OSv's native-example application instance
> in Ubuntu, and then I want to monitor OSv's system indicators, such as CPU
> usage, memory usage, network traffic, etc., but I don't know how to do it.
> How to do it, can you help answer it? thanks！！！
>
> --
> You received this message because you are subscribed to the Google Groups
> "OSv Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to osv-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/osv-dev/03f7ada4-187d-4c32-a585-f3ae82f68da1n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osv-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osv-dev/CAKUaUn4b8ZnQNV6QSRzr%3DszO2H%3DUXXp464qJQK-B9wVcQuHAqA%40mail.gmail.com.

Re: [osv-dev] Virtio-net poor parallel latency

['Dor Laor' via OSv Development]

On Mon, Mar 18, 2024 at 8:29 PM Darren L  wrote:

> Hello!
>
> Thank you for the suggestions. My testing environment is a i9-13900H,
> which has 20 total threads, of which I am allocating the first 8 to OSv and
> the next 4 to the client. These 12 in-use threads exist on 6 hyperthreaded
> cores.
>
> I wasn't sure how to measure the vmexits and/or process scheduling on the
> host.
>

https://access.redhat.com/solutions/6994095
Guest/hypervisor efficiency is many times a function of how many times the
guest
exits to the host. Lower is better


>
> I didn't see netperf on recent versions of OSv in the /tools, it seems to
> have existed in OSv v0.5 then afterwards was removed. I did run a similar
> benchmark on Python 3.10 and ran the same parallel tests, and I received
> much lower latency numbers compared to the Java 8 version. In this case, I
> received latency numbers of 45ms (min-max 18-63, std: 12) compared to a
> possibly confusing measurement for Linux VM of 837ms (min-max 39-1903, std:
> 817). If this does suggest that the JVM is the issue, what steps should I
> take to debug this problem? The application I am using must use Java 8 to
> run; it cannot be run on any other platform.
>

Eliminate Java is one option. Another is to use a recent JVM (17) and ZGC
and hopefully there wouldn't
be GC events (not sure it's a real issue here)


>
> I know these are not the exact details you requested, but I am more than
> happy to learn how I can capture the other details, if necessary. Thank you!
>
> On Wednesday, March 13, 2024 at 5:23:53 PM UTC-4 דור לאור wrote:
>
>> Lots of good details. It's not simple to figure out what's the issue
>> since
>> you have hypervisor, host, OS and JVM variables.
>>
>> How many threads does the host have? Make sure there are enough hardware
>> threads for the
>> guest, virtio on the host and the client. This way all
>> OSv's runable threads will be schedulable.
>> You can also measure the amount of vmexits and process scheduling on the
>> host.
>> There is a chance the JVM is an issue too, can you do the same with
>> netperf?
>>
>>
>> On Wed, Mar 13, 2024 at 9:14 PM Darren L  wrote:
>>
>>> Hello!
>>>
>>> I was wondering if I could get any pointers on why I am receiving
>>> significant latency issues using the virtio-net driver when processing
>>> multiple parallel clients. Hopefully I can explain my issue enough to be
>>> replicated.
>>>
>>> *Testing environment:*
>>> - Comparison: Ubuntu Server (Linux) VM and OSv (used the option "-nv" in
>>> the run.py script for tap networking)
>>> - In common: 4 CPU cores, 4GB of RAM, QEMU KVM, used "taskset" to pin to
>>> the same cores
>>> - Program: *java-httpserver* program from the apps directory, java8
>>> - What was sent: data of varying sizes (1KB to 1MB, 4MB, 8MB...) on the
>>> same machine to the VMs
>>>
>>> *Observations:*
>>> - With single-threaded requests and low data sizes, I was able to
>>> measure a latency on OSv that is lower than the Linux VM latency
>>> - example: for 32KB I measured ~4ms for OSv and 9.8ms for the Linux
>>> VM
>>> - At high data sizes (256KB+), OSv started to measure a higher latency
>>> than the Linux VM
>>> - When I sent *multiple requests* at the same time, OSv suffered a much
>>> larger average latency penalty
>>> - example, at 1MB data size and 16 parallel requests, average
>>> latency was:
>>> - OSv: 120ms (min-max 14-225ms, std: 62ms)
>>> - Linux VM: 82ms (min-max 24-144ms, std: 34ms) for the Linux VM
>>>
>>> *Other notes:*
>>> - I've been using the OSv profiling tools and have seen that the hot
>>> spots typically were in virtio::virtio_driver::wait_for_queue and
>>> virtio::net::receiver, but I was unable to identify the exact issue on why
>>> this latency is the case
>>> - I also noticed when tracing the network layer (
>>> https://github.com/cloudius-systems/osv/wiki/Trace-analysis-using-trace.py#tracing-network-layer),
>>> there were a lot of *net_packet_handling* lines; about as much as there
>>> were *net_packet_in* lines for 1MB, which might indicate that the
>>> packets are not being processed fast enough and are delayed because it is
>>> put in a queue?
>>>
>>> Hope this is clear enough! I am hoping to understand whether I am
>>> misconfiguring OSv or something similar to figure out why this latency
>>> difference is occurring. Thank you for the help in advance, and happy to
>>> provide any more information as needed.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "OSv Development" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to osv-dev+u...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/osv-dev/0ace3980-5036-4df9-9e46-7396bb20ce9fn%40googlegroups.com
>>> 
>>> .
>>>
>> --
> You received 

Re: [osv-dev] Virtio-net poor parallel latency

['Dor Laor' via OSv Development]

Lots of good details. It's not simple to figure out what's the issue since
you have hypervisor, host, OS and JVM variables.

How many threads does the host have? Make sure there are enough hardware
threads for the
guest, virtio on the host and the client. This way all
OSv's runable threads will be schedulable.
You can also measure the amount of vmexits and process scheduling on the
host.
There is a chance the JVM is an issue too, can you do the same with netperf?


On Wed, Mar 13, 2024 at 9:14 PM Darren L  wrote:

> Hello!
>
> I was wondering if I could get any pointers on why I am receiving
> significant latency issues using the virtio-net driver when processing
> multiple parallel clients. Hopefully I can explain my issue enough to be
> replicated.
>
> *Testing environment:*
> - Comparison: Ubuntu Server (Linux) VM and OSv (used the option "-nv" in
> the run.py script for tap networking)
> - In common: 4 CPU cores, 4GB of RAM, QEMU KVM, used "taskset" to pin to
> the same cores
> - Program: *java-httpserver* program from the apps directory, java8
> - What was sent: data of varying sizes (1KB to 1MB, 4MB, 8MB...) on the
> same machine to the VMs
>
> *Observations:*
> - With single-threaded requests and low data sizes, I was able to measure
> a latency on OSv that is lower than the Linux VM latency
> - example: for 32KB I measured ~4ms for OSv and 9.8ms for the Linux VM
> - At high data sizes (256KB+), OSv started to measure a higher latency
> than the Linux VM
> - When I sent *multiple requests* at the same time, OSv suffered a much
> larger average latency penalty
> - example, at 1MB data size and 16 parallel requests, average latency
> was:
> - OSv: 120ms (min-max 14-225ms, std: 62ms)
> - Linux VM: 82ms (min-max 24-144ms, std: 34ms) for the Linux VM
>
> *Other notes:*
> - I've been using the OSv profiling tools and have seen that the hot spots
> typically were in virtio::virtio_driver::wait_for_queue and
> virtio::net::receiver, but I was unable to identify the exact issue on why
> this latency is the case
> - I also noticed when tracing the network layer (
> https://github.com/cloudius-systems/osv/wiki/Trace-analysis-using-trace.py#tracing-network-layer),
> there were a lot of *net_packet_handling* lines; about as much as there
> were *net_packet_in* lines for 1MB, which might indicate that the packets
> are not being processed fast enough and are delayed because it is put in a
> queue?
>
> Hope this is clear enough! I am hoping to understand whether I am
> misconfiguring OSv or something similar to figure out why this latency
> difference is occurring. Thank you for the help in advance, and happy to
> provide any more information as needed.
>
> --
> You received this message because you are subscribed to the Google Groups
> "OSv Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to osv-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/osv-dev/0ace3980-5036-4df9-9e46-7396bb20ce9fn%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osv-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osv-dev/CAKUaUn7hAB6AqhXJ4ozOU-pHRdFTobfH3QFXdaUcz395C15yHw%40mail.gmail.com.

Re: [osv-dev] FOSDEM24 Presentation

['Dor Laor' via OSv Development]

Waldek, do you have some standard Linux apps you tested that can be
just loaded to OSv? Will be nice to showcase OSv values, with either
performance or VM convenience when you take an app and quickly boot
it with OSv and it just works.


On Thu, Feb 1, 2024 at 3:11 PM Waldek Kozaczuk  wrote:

> If you happen to be at #FOSDEM
>  in Brussels this
> coming weekend and are interested in recent improvements to the OSv ,
> please come to watch my presentation -
> https://fosdem.org/2024/schedule/event/fosdem-2024-3483-support-dynamically-linked-executables-via-linux-ld-so-and-implement-ena-driver-to-expand-application-of-osv/
>
> "From the beginning, OSv has been designed to implement a subset of the
> Linux flavor of POSIX API. Initially, most Linux applications had to be
> re-compiled from source as shared libraries. Starting with the release
> 0.54.0, it has become possible to run unmodified Linux position-independent
> executables (so-called "PIEs") and position-dependent executables "as-is".
>
> In my presentation, I will talk about how OSv has been enhanced to support
> running statically linked executables. Not only that, the same improvements
> make it possible to execute dynamically linked executables via Linux
> dynamic linker. I will also briefly describe a newly added strace-like
> capability aimed to help analyze system calls on the fly.
>
> In addition, I will explain how we have implemented the ENA networking
> driver and thus made it possible to run OSv on AWS Nitro EC2 instances.
> Finally, I will briefly cover the upcoming build configuration tool, based
> on Xconfig, aimed to let the user select OSv kernel components to be
> included or excluded and various parameters to be configured."
>
> Cheers,
> Waldek
>
> --
> You received this message because you are subscribed to the Google Groups
> "OSv Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to osv-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/osv-dev/877de531-b8f4-4680-a065-4965528951a2n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osv-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osv-dev/CAKUaUn7KSrxu17hvpN4Pqda4ATi21JSpLk8rcT662LxDxBpP%2BQ%40mail.gmail.com.

Re: [osv-dev] ENA driver

['Dor Laor' via OSv Development]

Sweat!

On Thu, Nov 30, 2023 at 7:52 AM Waldek Kozaczuk 
wrote:

> Hi,
>
> I have just created a pull request that implements OSv ENA driver by
> porting the FreeBSD version -
> https://github.com/cloudius-systems/osv/pull/1283. If you have bandwidth
> and know-how please feel free to review this PR.
>
> This is enough to run OSv on a nitro instance like t3 nano with ramfs
> image (ideally we would like NVMe driver). I have only tested it with
> simple golang httpserver and OSv http monitoring module and only on t3
> nano. It seems to be functional and stable but I still need to run more
> tests to get a better feel.
>
> Regards,
> Waldek
> [image: i-060143e9381af3d55.jpg]
>
> --
> You received this message because you are subscribed to the Google Groups
> "OSv Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to osv-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/osv-dev/32a2dfa7-9407-4a1a-a4fc-5711401dfec8n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osv-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osv-dev/CAKUaUn4QtA%3DmD97i%3Degw5OSaMHqP6T9GUq4-px%3D7Ahvyi%2BkLAA%40mail.gmail.com.

Re: [osv-dev] OSv and Genezio presentations

['Dor Laor' via OSv Development]

On Tue, Aug 8, 2023 at 10:32 PM Waldek Kozaczuk 
wrote:

> Hi,
>
> I am back after a family summer break vacation so you should hear from me
> more often hopefully.
>
> I would also like to share links to the OSv presentation I gave a month
> ago on the Unikernel Alliance forum:
> - recording:
> https://www.youtube.com/watch?v=KnzRnKTCmjc=PLnqfImRjARAjX5veufPxCkGYntfsl8Eb_=3
> - slides PDF:
> https://drive.google.com/file/d/1XPzjLPRnq58HzW84yn98Ut7GVbOp6_cq/view?pli=1
> - slides on Google docs:
> https://docs.google.com/presentation/d/1-dlart1tFslsdjZVajkKpbyREN0UKGoIo55HvZtAl9s/edit?usp=sharing
>
> I would also like to share the presentation by the Genezio team that has
> been building their serverless platform based on OSv:
>
> - recording:
> https://www.youtube.com/watch?v=xRmRXCY_h6I=PLnqfImRjARAjX5veufPxCkGYntfsl8Eb_=4
> - slides PDF:
> https://drive.google.com/file/d/1G_41wvszW8WAgOW1m108_cAP1SZ5lkOC/view?usp=drive_link
>

Nice to see a real life use case !


>
> Enjoy,
> Waldek Kozaczuk
>
> --
> You received this message because you are subscribed to the Google Groups
> "OSv Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to osv-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/osv-dev/853de34d-67aa-470b-96c1-16f6e8fb7589n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osv-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osv-dev/CAKUaUn7LFYdRg6d%2Bj6%2BWbCXJBhi9Cnc0h8Na0HEkQJ80i2COOw%40mail.gmail.com.

Re: [osv-dev] OSv can run statically linked executable

['Dor Laor' via OSv Development]

Very impressive, it improves OSv's ability to be a very safe and
fast sandbox

On Mon, Apr 24, 2023 at 6:26 AM Waldek Kozaczuk 
wrote:

> Hi,
>
> Over the recent week, I have been working to get OSv to run a simple
> "hello world" app (aka native-example) built as a position-dependent
> statically linked executable. In essence, I picked up where Pekka Enberg
> left over 8 years ago (see
> https://github.com/cloudius-systems/osv/tree/static-elf). Obviously,
> given these days OSv has pretty robust support of over 70 syscalls (and 60
> more that should be trivial to add), and the remaining work is much more
> manageable.
>
> ./scripts/firecracker.py -e /hello
> OSv v0.57.0-37-g0de155a4
> Booted up in 5.23 ms
> Cmdline: /hello
>  -> syscall: 107
>  -> syscall: 102
>  -> syscall: 108
>  -> syscall: 104
>  -> syscall: 158
>  -> syscall: 012
>  -> syscall: 012
>  -> syscall: 158
>  -> syscall: 218
>  -> syscall: 273
>  -> syscall: 063
>  -> syscall: 302
>  -> syscall: 089
>  -> syscall: 318
>  -> syscall: 228
>  -> syscall: 228
>  -> syscall: 012
>  -> syscall: 012
>  -> syscall: 010
>  -> syscall: 262
>  -> syscall: 016
>  -> syscall: 001
> Hello from C code
>  -> syscall: 231
>
> I will be sending a series of proper patches later after I clean some
> issues but in essence here is a list of things I had to do including what
> Pekka started:
>
>1. Tweak dynamic linker to support static executable:
>   - Handle missing DT_SYMTAB, DT_STRTAB and DT_NEEDED.
>   - Handle ET_EXEC
>   - Support statically-linked executable base address
>2. Add basic handling of static ELF entry point and initial stack
>state setup (see figure 3.9 ("Initial Process Stack") of the x86-64 ABI
>specification - https://refspecs.linuxbase.org/elf/x86_64-abi-0.99.pdf
>   - make sure the RDX registers in zeroed and the basic AUX vector
>   with AT_RANDOM is set up
>   - more is left to do to fully support argv and full aux vector
>3. Add support of the brk() syscall (see issue 1138)
>4. Add dummy support of sys_set_robust_list and set_tid_address
>syscalls (possibly needs something more for multithreaded apps).
>5. Support the arch_prctl syscall that sets the app TLS
>   - this was by far the most complicated element that required
>   changing OSv to store new per-pcpu data pointer in GS register and
>   enhancing both syscall handler and interrupt/page fault handler to 
> detect
>   and switch if needed the FS base to the kernel TLS on entry and back to 
> the
>   app one on exit (see
>   
> https://github.com/cloudius-systems/osv/issues/1137#issuecomment-1512315880
>   )
>6. Fixing a potential bug in handling TCGETS in the console driver.
>7. Implement sys_prlimit
>8. Enable the readlink, geteuid and getegid
>
> This was enough to run a single-threaded app but we will need to implement
> the clone syscall to support multi-threaded apps. In addition, we would
> want to support the static pies as well which I hope should not be very
> difficult.
>
> Regards,
> Waldek
>
> --
> You received this message because you are subscribed to the Google Groups
> "OSv Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to osv-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/osv-dev/3a561595-e072-4980-8375-3b742717dd6dn%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osv-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osv-dev/CAKUaUn4WwpOOrYq9-9CF5M4LCzOTqXWhPhWqPunnpdfu2uVZRQ%40mail.gmail.com.

Re: [osv-dev] OSv talk

['Dor Laor' via OSv Development]

On Thu, Feb 9, 2023 at 5:49 AM Waldek Kozaczuk  wrote:

> The video of the talk has been just released and you can watch it here -
> https://fosdem.org/2023/schedule/event/osvevolution/ (the play button
> should play it). There are also slides attached on that page below.
>
> If you want to see the version of the slides with presenter notes, here
> you go -
> https://docs.google.com/presentation/d/1xcKLI-txmS0_T9QUgo6msRaOGzreU22x-Gzn9beh46I/edit?usp=sharing.
> At the end of the talk I ran out of time so that way you can read
> everything I was supposed to say there.
>
> I hope you will enjoy my talk if you have not watched it live.
>
> Nadav,
> You are right! We might want to jump to a version like 1.0 - maybe it is
> finally time for it anyway.
>

I agree. OSv celebrates 10 years this 2023.
Well done Waldek! Outstanding work and great presentation.


>
> Waldek
>
> On Sunday, February 5, 2023 at 8:24:30 AM UTC-5 n...@scylladb.com wrote:
> On Sun, Feb 5, 2023 at 10:23 AM Nadav Har'El  wrote:
>
> On Sun, Feb 5, 2023 at 9:56 AM Waldek Kozaczuk  wrote:
> If you are going to happen to have some time today from 12AM - 1PM
> Brussels time, please watch my talk here at
> https://fosdem.org/2023/schedule/event/osvevolution/. It should be
> streamable live.
>
> Regards,
> Waldemar Kozaczuk
>
> Good luck!
>
> I'll try to watch live, I'm sure it will be interesting.
>
> Indeed it was interesting!
> Version "0.57"  was for sure a bigger accomplishment than the version
> number suggests.
> And thanks for mentioning me :-)
>
> I hope they will have the recording available somewhere later, in case
> someone missed the live feed.
>
> Nadav.
>
> --
> You received this message because you are subscribed to the Google Groups
> "OSv Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to osv-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/osv-dev/4ec729c1-9a4d-40dd-a27b-a2132ecaf31cn%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osv-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osv-dev/CAKUaUn6v2j5X3wPz61z66-NFwoUG-F08zDXH-qHn7-h4QWiq5Q%40mail.gmail.com.

Re: [osv-dev] Evolution of OSv: Towards Greater Modularity and Composability

['Dor Laor' via OSv Development]

Highly recommended, cheers Waldek!

On Fri, Dec 30, 2022 at 3:22 PM Waldek Kozaczuk 
wrote:

> Hi,
>
> If you happen to be in Brussels at the beginning of February, I will be
> giving a talk at FOSDEM 2023 about recent improvements to OSv. Feel free to
> stop by to listen or watch it after:
>
> https://fosdem.org/2023/schedule/event/osvevolution/
>
> Regards,
> Waldek
>
> --
> You received this message because you are subscribed to the Google Groups
> "OSv Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to osv-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/osv-dev/3158f9c9-8f47-4ee6-bf83-3162cf850d3cn%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osv-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osv-dev/CAKUaUn5NNH053jhd8SbibG8GSJfak-nJNrUL31Uvgx%2BKTe79cQ%40mail.gmail.com.

Re: [osv-dev] Re: Save the date: Oct 7th, 2021 and watch OSv presentation at p99 conference

[Dor Laor]

Waldek, excellent presentation and really good results!
Do you have new tests with SO_REUSE you mentioned?


On Sat, Oct 9, 2021 at 2:29 AM Timothy P  wrote:

> Hi,
>
> Long time lurker in this group and follower of OSv's progress.
>
> Waldek, I would like to say how much I enjoyed your talk at the P99 event…
> and also to say thanks for publicising the conference as there were many
> interesting topics covered.
>
> Tim
>
> --
> You received this message because you are subscribed to the Google Groups
> "OSv Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to osv-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/osv-dev/3f59741e-94c2-4433-b640-dc541b3a7c10n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osv-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osv-dev/CAKUaUn4UXJocAWWXbJyW%2Bd8NrX6rbYkU39%3Db0gU_JPAYWSpNKw%40mail.gmail.com.

Re: [osv-dev] Contributing to osv.io

[Dor Laor]

Sure, in the case of a single article, best is to post it to the list
for review and add a target location, if it's multiple changes, we
can eventually add you to the www github project

On Thu, Feb 11, 2021 at 8:09 AM Matthew Kenigsberg <
matthewkenigsb...@gmail.com> wrote:

>
> Hi,
>
> Is there somewhere I can contribute to docs on osv.io?
>
> Thanks,
> Matthew
>
> --
> You received this message because you are subscribed to the Google Groups
> "OSv Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to osv-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/osv-dev/c7dede83-c5c9-4bbb-ae8b-af900348f58en%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osv-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osv-dev/CAKUaUn7BJz7FXEao42WjP1Eewf-eveGMRUb_z%3DrbW3yrBmWxjw%40mail.gmail.com.

Re: [osv-dev] Re: OSv in QEMU blog

[Dor Laor]

Impressive work and numbers! Worth to link the presentation from the blog
since I was looking for those numbers too.

On Fri, Nov 13, 2020 at 12:29 PM Waldek Kozaczuk 
wrote:

> Fotis,
>
> Congratulations on your article and diploma! I have looked at the slides -
> https://github.com/foxeng/diploma/blob/master/slides.pdf - but I cannot
> read Greek :-)
>
> Regards,
> Waldek
>
> PS. It would be nice to see some improved tooling around virtio-fs in
> capstan and so on.
> On Thursday, November 12, 2020 at 5:09:07 PM UTC-5 Fotis Xenakis wrote:
>
>> Hello everyone,
>>
>> OSv is featured in the most recent post on QEMU's blog [1], with regard
>> to its usage of virtio-fs. I was invited to write that post after the
>> virtio-fs devs showed interest in our use case. Also, I 'd like to
>> apologize for omitting to include you in the original discussion (should be
>> more inclusive in the future).
>>
>> Regards,
>> Fotis
>>
>> [1] https://www.qemu.org/2020/11/03/osv-virtio-fs/
>>
> --
> You received this message because you are subscribed to the Google Groups
> "OSv Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to osv-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/osv-dev/68720f34-f908-491d-ad9e-e5e175ab741cn%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osv-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osv-dev/CAKUaUn4wT%2B%2B4gQ2L3hL1WSUyBUGjoc84yPFKsyS1jCoCL5J-XQ%40mail.gmail.com.

Re: [osv-dev] Problems with socat

[Dor Laor]

Best is to put a breakpoint and start single stepping and read
those variable values

On Wed, Jul 22, 2020 at 5:57 PM Rick Payne  wrote:

>
> Trying to characterise some performance stuff, I thought I'd run socat
> under OSv however it panics:
>
> $ sudo scripts/run.py -n -e 'socat tcp4-listen:6971 open:/dev/null'OSv
> v0.55.0
> eth0: 192.168.122.76
> Booted up in 3245.70 ms
> Cmdline: socat tcp4-listen:6971 open:/dev/null
> Assertion failed: type == SOCK_STREAM (libc/af_local.cc:
> socketpair_af_local: 101)
>
> [backtrace]
> 0x402228ae 
> 0x40222917 <__assert_fail+64>
> 0x406fb1d0 
> 0x40246c37 
> 0x10034587 
> 0x657473696c2d346f 
>
> The particular function in socat which triggers this is:
>
> static int diag_sock_pair(void) {
>int handlersocks[2];
>
>if (socketpair(AF_UNIX, SOCK_DGRAM, 0, handlersocks) < 0) {
>   diag_sock_send = -1;
>   diag_sock_recv = -1;
>   return -1;
>}
>diag_sock_send = handlersocks[1];
>diag_sock_recv = handlersocks[0];
>return 0;
> }
>
> And in OSv:
>
> #5  0x406fb1d1 in socketpair_af_local (type=2, proto=0,
> sv=0x20700b20) at libc/af_local.cc:101
> 101assert(type == SOCK_STREAM);
>
> Not sure why this restriction exists, and I've changed my local socat
> to use SOCK_STREAM - but just thought we should note a difference
> between linux and OSv here...
>
> Rick
>
> --
> You received this message because you are subscribed to the Google Groups
> "OSv Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to osv-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/osv-dev/f604ee0d7c79713f24744c47903f5e5515bfbb3f.camel%40rossfell.co.uk
> .
>

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osv-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osv-dev/CAKUaUn6tKXEvQZdB9ymzaBGFEj%3DUwRNQGqVMPqk439v7CpoipA%40mail.gmail.com.

Re: [osv-dev] Building customized kernel

[Dor Laor]

On Thu, Jun 11, 2020 at 6:33 AM Waldek Kozaczuk 
wrote:

>
>
> On Thursday, June 11, 2020 at 2:25:06 AM UTC-4 Pekka Enberg wrote:
>
>> Hi Dor,
>>
>> On Thu, Jun 11, 2020 at 8:21 AM Dor Laor  wrote:
>>
>>> Waldek, can you please describe what's your motivation in shrinking
>>> the size of the kernel? Compared for example to modern RAM and also
>>> to the JVM that many times will be there, the current size is already
>>> 'small enough', isn't it?
>>>
>>
>> Not necessarily if the lifetime of a VM is in the order of, say, hundreds
>> of milliseconds.
>>
>> My understanding is that these extreme optimizations to reduce size are
>> motivated by the emergence of light-weight VMs, which allow cloud providers
>> to launch VMs on-demand for a group of service requests. This allows them
>> to more efficiently utilize the hardware because an idle VM still consumes
>> some resources. And in any case, smaller image size anyway means shorter
>> boot time and more packing of VMs per node.
>>
> Exactly. The density is the main motivation. But also somewhat better
> security - the app has only access to (in terms of the dynamic linker at
> least) to the subset of libc so at least in theory it should not be able to
> do anything else than advertised per its ELF.
>
> With the kernel of size 2.7M we can run hello app on OSv with 11M memory
> only (~5MB less) and boot 1-2ms faster - now I pretty consistently get boot
> times of ~4ms on firecracker (20-30% faster).
>

4ms is pretty amazing, it makes OSv+kvm/firecracker a good candidate for
lambdas.
For heavier weight frameworks like JVMs, the best would be to preboot them
and
load the app dynamically.


>
> Another advantage is that there are fewer symbols in the kernel the
> dynamic linker has to search to resolve. I know it uses a hashmap that
> makes things pretty fast already but still smaller the hashmap with smaller
> buckets the faster lookup should be.
>
> Finally, whatever mechanism to build custom kernels is, it should also
> account for the usage of syscall instruction and properly eliminate stuff
> from linux.cc so that the linker can garbage collect even better.
>
>>
>> - Pekka
>>
> --
> You received this message because you are subscribed to the Google Groups
> "OSv Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to osv-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/osv-dev/1af0216b-a783-47d5-972c-6ea3d5eb262an%40googlegroups.com
> <https://groups.google.com/d/msgid/osv-dev/1af0216b-a783-47d5-972c-6ea3d5eb262an%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osv-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osv-dev/CAKUaUn6BqT5JcbjwGUmcUq-Ey2NVofN_za47TSx_FAFBKpvnoA%40mail.gmail.com.

Re: [osv-dev] Building customized kernel

[Dor Laor]

Waldek, can you please describe what's your motivation in shrinking
the size of the kernel? Compared for example to modern RAM and also
to the JVM that many times will be there, the current size is already
'small enough', isn't it?

On Wed, Jun 10, 2020 at 9:55 PM Waldek Kozaczuk 
wrote:

> Imagine we wanted to allow building a kernel that is customized to a
> specific app - in other words, it provides more-less only the functionality
> needed by the aforementioned app and nothing more. Please note that one of
> the previous conversations was about creating "microVM" version of the
> kernel.elf which is also customized but to a specific type of hypervisor.
> So how could we achieve this?
>
> It turns out it is now that difficult as long as we rely on a
> version script and the linker garbage collecting all unneeded code and
> data. All we need to do is to manufacture a custom version script that
> exports symbols only needed by the given app. For example, a native hello
> world would have a version script like this:
>
> {
>   global:
>  __cxa_finalize;
>  __gmon_start__;
>  _ITM_deregisterTMCloneTable;
>  _ITM_registerTMCloneTable;
>  __libc_start_main;
>  puts;
>
>   local:
> *;
> };
>
> I have hand-crafted it but it can be quite easy to automate the generation
> of it like this:
>
> nm -uD apps/native-example/hello
>
> After re-linking with this specific version script we arrive with
> kernel.elf that is only 2.7M in size (2728432 bytes) and exposes 3 symbols
> only:
>
> nm -CD build/release/kernel.elf
> 402233b0 T __cxa_finalize
> 403211c0 T __libc_start_main
> 40357480 T puts
>
> The size difference is around 10% which is not that dramatic but one
> advantage is that the kernel exposes only symbols needed by the app so it
> is somewhat more secure.
>
> I have also experimented with more non-trivial apps like redis and tomcat
> (java) and even then the resulting kernel.elf was still around 2.7M
> (2826976 bytes) and around 400 symbols exposed. For java that depends on
> many shared libraries and I had to sum all the needed symbols sets and
> intersect them with the ones from the generic kernel version script.
>
> Please note that the above-sketched recipe to produce customized kernel
> does not require re-compiling any kernel sources but only re-linking the
> final artifact - kernel.elf - to provide only needs symbols and eliminate
> any unneeded code and data. Which means it is pretty fast (unless you start
> using lto about which I will write later).
>
> Waldek
>
> --
> You received this message because you are subscribed to the Google Groups
> "OSv Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to osv-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/osv-dev/da86ac70-a301-47e0-a870-1b4a1b3b4913n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osv-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osv-dev/CAKUaUn4c%2Bg2FVjbM3BA1OJprC_1_UWUrEChGaMEQj8RrAX_BFQ%40mail.gmail.com.

Re: [osv-dev] OSv boots and runs simple hello world on Firecracker ARM edition ... on Raspberry PI 4

[Dor Laor]

Kudos Waldek!

On Thu, May 21, 2020 at 1:58 PM Waldek Kozaczuk 
wrote:

>
> *ubuntu@ubuntu-rasp4*:*~*$ uname -a
>
> Linux ubuntu-rasp4 5.3.0-1025-raspi2 #27-Ubuntu SMP Fri May 8 08:32:04
> UTC 2020 aarch64 aarch64 aarch64 GNU/Linux
>
> *ubuntu@ubuntu-rasp4*:*~*$ ./firecracker-v0.21.1-aarch64 --no-api --config
> -file ./osv-config.json
>
> OSv v0.55.0-9-g840428ad
>
> PSCI: version 65536.0 detected.
>
> setup_arm_clock() ENTERED, lr=800d54e0
>
> arm_clock(): frequency read as 0337f980
>
> interrupt_table::interrupt_table() ENTERED, lr=800a8d1c
>
> gic_driver::init_cpu() ENTERED, lr=80201c80
>
> CPU interface enabled.
>
> gic_driver::init_dist() ENTERED, lr=80201c8c
>
> number of supported IRQs: 0080
>
> interrupt table: gic driver created.
>
> registered IRQ id=0004
>
> registered IRQ id=001b
>
> registered IRQ id=
>
> Premain complete!
>
> smp_launch ENTERED, lr=800d709c
>
> Booted up in 0.00 ms
>
> Cmdline: console=ttyS0 --verbose --nomount --maxnic=0 /tools/hello.so
> earlycon=uart,mmio,0x40001000
>
> faulting address 1001fea0
>
> faulting address 1328
>
> faulting address 1002
>
> faulting address 10050018
>
> faulting address 100301c8
>
> faulting address 1004fe00
>
> Hello from C code
>
> 2020-05-21T20:24:04.080765641 [anonymous-instance:ERROR:src/vmm/src/vstate
> .rs:951] Unexpected exit reason on vcpu run: SystemEvent
>
> In general it took me a bit of research as I am not really familiar with
> ARM architecture and even reading the assembly was a bit a challenge to say
> the least. And then debugging without debugger and any console (:-( .. so
> not debug() for long time. But all in all it was not too bad and the
> changes that I had to make to OSv are in my opinion much smaller and easier
> comparing to x86_64.
>
> Below you will see the "hack-patch" showing what changes I had to make.
> Logically, following things had to be changed:
>
>- The most important thing was to move kernel from 0x4000 (1GB) to
>0x8000 (2GB) which required changing one line in Makefile (see below)
>and changing boot paging table to map the 2GB-3GB area of memory; only then
>I could actually start debugging :-) I wonder if it will also work on
>QEMU/KVM - possinly qemu boot loader will inspect ELF and place it
>accordingly in memory; firecracker does not read ELF and simply places it
>at 2GB
>- To get console working I guessed that that need to create equivalent
>class for isa_serial_console but communicating over mmio (see
>mmio_isa_serial_console.hh/cc) which in essence invokes mmio_set*/mmio_get*
>(it would be nice to extract common code somehow - suggestions welcome)
>- Some more trivial changes - for now mostly disabling things - for
>now quite disorganized
>
>
> diff --git a/Makefile b/Makefile
> index db3c68cf..ffd570a5 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -354,6 +354,7 @@ tools := tools/mkfs/mkfs.so tools/cpiod/cpiod.so
>  $(out)/tools/%.o: COMMON += -fPIC
>
>  tools += tools/uush/uush.so
> +tools += tools/uush/hello.so
>  tools += tools/uush/ls.so
>  tools += tools/uush/mkdir.so
>
> @@ -451,8 +452,8 @@ endif # x64
>
>  ifeq ($(arch),aarch64)
>
> -kernel_base := 0x4008
> -kernel_vm_base := 0x4008
> +kernel_base := 0x8008
> +kernel_vm_base := 0x8008
>  app_local_exec_tls_size := 0x0
>
>  include $(libfdt_base)/Makefile.libfdt
> @@ -816,6 +817,7 @@ drivers += drivers/xenplatform-pci.o
>  endif # x64
>
>  ifeq ($(arch),aarch64)
> +drivers += drivers/mmio-isa-serial.o
>  drivers += drivers/pl011.o
>  drivers += drivers/xenconsole.o
>  drivers += drivers/virtio.o
> diff --git a/arch/aarch64/arch-dtb.cc b/arch/aarch64/arch-dtb.cc
> index b59f1dcc..cd0719e8 100644
> --- a/arch/aarch64/arch-dtb.cc
> +++ b/arch/aarch64/arch-dtb.cc
> @@ -225,7 +225,8 @@ bool dtb_get_gic_v2(u64 *dist, size_t *dist_len, u64
> *cpu, size_t *cpu_len)
>  if (!dtb)
>  return false;
>
> -node = fdt_node_offset_by_compatible(dtb, -1, "arm,cortex-a15-gic");
> +//node = fdt_node_offset_by_compatible(dtb, -1, "arm,cortex-a15-gic");
> +node = fdt_node_offset_by_compatible(dtb, -1, "arm,gic-400");
>  if (node < 0)
>  return false;
>
> @@ -613,11 +614,13 @@ void  __attribute__((constructor(init_prio::dtb)))
> dtb_setup()
>  abort("dtb_setup: failed to parse cpu mpid.\n");
>  }
>
> +//TODO: Parse PCI only if required and
> +// abort if missing only if required
>  dtb_timer_irq = dtb_parse_timer_irq();
>  dtb_pci_irqmask = dtb_parse_pci_irqmask();
>  dtb_pci_irqmap_count = dtb_parse_pci_irqmap_count();
>  if (!dtb_parse_pci_irqmap(dtb_pci_bdfs, dtb_pci_irq_ids,
> dtb_pci_irqmap_count)) {
> -abort("dtb_setup: failed to parse pci_irq_map.\n");
> +//abort("dtb_setup: failed to parse pci_irq_map.\n");
>  }
>
>  register u64 edata;

Re: [osv-dev] Benchmarking OSv

[Dor Laor]

It depends on many factors. You should check what's the bottleneck first.
I'd start with a single core and later with 2 cores and grow it exponentially.
It either may be the IO overhead (most chances the network
virtualization) or the
cpu overhead with regard to locking. OSv has a different filesystem too.
Let's see what you have to share first.

On Mon, Feb 24, 2020 at 6:32 PM  wrote:
>
> Running some benchmarks on OSv. Getting some results opposite to what I was 
> expecting based off what I have learned of unikernels. When running my 
> benchmark on the host with 32 cores, it runs in about 2s. However, when 
> running the OSv build inside on KVM (run.py), I pass in 32 cores and it takes 
> 9s to complete. My assumption was it would be the same speed, possibly 
> faster. Any ideas as to why the decrease?
>
> --
> You received this message because you are subscribed to the Google Groups 
> "OSv Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to osv-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/osv-dev/cac7dca2-eaa3-4c66-a8b7-705182e67942%40googlegroups.com.

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osv-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osv-dev/CAKUaUn7NHQ1mFLQwANH6%2BF1NXx%2ByOzRQ8eYjN_GD3qTF9o2adQ%40mail.gmail.com.

Re: [osv-dev] Fail to read data from large file

[Dor Laor]

A classical good OSS reporter and a good (!) committer

On Tue, Jan 14, 2020 at 2:47 AM Nadav Har'El  wrote:
>
> On Tue, Jan 14, 2020 at 12:41 PM Lewis Tian  wrote:
>>
>>
>>
>> On Tuesday, January 14, 2020 at 4:45:27 PM UTC+8, Nadav Har'El wrote:
>>>
>>>
>>> Interesting. Smells like a serious stdio bug that needs to be debugged :-(
>>> I think it's not a coincidence that position is 1025, with stdio's 
>>> BUFSIZ=1024.
>>>
>>> Just as a completely wild guess, can you please try if the following patch 
>>> to libc/internal/shgetc.c helps?
>>>
>>> @@ -22,5 +22,6 @@
>>>   else
>>>   f->shend = f->rend;
>>>   if (f->rend) f->shcnt += f->rend - f->rpos + 1;
>>> + if (f->rpos[-1] != c) f->rpos[-1] = c;
>>>   return c;
>>>  }
>>>
>>
>> Yeah, the patch is helpful! Thanks! : )
>
>
> I'm pleasantly surprised :-) I'll send a more organized patch to the mailing 
> list.
>>
>>



>
>
>>
>> When I use a small graph (4 nodes, 7 edges), it runs normally.
>>
>> taseikyo@ubuntu:~/Desktop/osv$ ./scripts/build image=my-pagerank-test
>> taseikyo@ubuntu:~/Desktop/osv$ ./scripts/run.py
>> OSv v0.54.0-71-g69a0ce39
>> eth0: 192.168.122.15
>> Booted up in 356.44 ms
>> Cmdline: /pagerank
>>
>> Graph data:
>>
>>   Nodes: 4, Edges: 7
>>
>>
>> Number of iteration to converge: 41
>>
>> Final Pagerank values:
>>
>> [0.159913 , 0.144016 , 0.144016 , 0.082809 ]
>>
>> Time spent: 0.693802 seconds.
>>
>> Is osv unable to read large files (bug?) I'll appreciate your help very 
>> much! : )
>>
>> --
>> You received this message because you are subscribed to the Google 
>> Groups "OSv Development" group.
>> To unsubscribe from this group and stop receiving emails from it, send 
>> an email to osv...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/osv-dev/50f3a073-e364-484c-803e-570e0dd6530c%40googlegroups.com.

 --
 You received this message because you are subscribed to the Google Groups 
 "OSv Development" group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to osv...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/osv-dev/ae3d8e59-bb13-40a4-bdd0-b03ec89b9ff3%40googlegroups.com.
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "OSv Development" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to osv-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/osv-dev/9e83516e-d25f-4409-a15d-a0a59871978d%40googlegroups.com.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "OSv Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to osv-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/osv-dev/CANEVyjva7W44mktoixKtdprxbEyXNt1qg7%3D%3D6qNatcH3xAGAfA%40mail.gmail.com.

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osv-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osv-dev/CAKUaUn7vw-e7stMfFxmUsJEuMqiQUp0KTAjxF6YuYDd0cW_edA%40mail.gmail.com.

Re: [osv-dev] IPV6 branch

[Dor Laor]

Waldek, it's great that OSv is in such good hands!
With the growth of serverless and the shrinkage in qemu+osv boot time, it
opens lots of more use cases for our users.
Dor

On Thu, Dec 12, 2019 at 3:03 PM Waldek Kozaczuk 
wrote:

> Hi,
>
> Yesterday I merged the IPV6 patches submitted by Charles Myers from
> Spirent over a year ago -
> https://groups.google.com/d/msg/osv-dev/WJ52lvQtC9Q/gCyNWsO0CwAJ - into a
> new branch *ipv6* (https://github.com/cloudius-systems/osv/tree/ipv6)
> based on the current master branch. These patches add IPV6 support as well
> as fix some bugs in OSv networking code which is based on FreeBSD 9
> codebase.
>
> The sheer breadth of the patches is enormous and gives a credit to the
> excellent work by Charles (great job!!!). Given that Nadav reviewed them
> and was generally happy with them, I thought it would be a shame if we let
> it get forgotten like this. Now, given it touches very sensitive and
> complicated networking code, I thought it would be wise to put it on a
> separate branch, test it more by the community and then merge it into
> master. Given the networking code does not change that often, we could
> somehow auto-merge master into it (does github offer such ability?).
>
> Most of the patches were merged without conflicts using 'git am -m', in
> some few cases I had to resolve some conflicts:
>
>- virtio-net, vmxnet code -
>
> https://github.com/cloudius-systems/osv/commit/ee7b0ef05016819fbb9eb0e9dc29ff343672af81
>- loader.cc where we replaced boost::program_options -
>
> https://github.com/cloudius-systems/osv/commit/723893512fefe58a9a86d1c7aab52fb99140b83a
>- unit tests Makefile -
>
> https://github.com/cloudius-systems/osv/commit/87fb81b91cd2d7fcbe11ca8418df444afa6ea430
>- minor conflicts in the main Makefile -
>
> https://github.com/cloudius-systems/osv/commit/47381fb07bad3274f411baeb0c39b2a96341aaec
>
> I did not apply one patch -
> https://groups.google.com/d/msg/osv-dev/WJ52lvQtC9Q/HAQW4y60BQAJ - with
> cloud init support - which seems to somewhat independent. Rick Payne
> mentioned that he might send a new version that addresses also the program
> options removal implications.
>
> I also had to fix number of gcc 8/9 compiler warnings by either adjusting
> the code to use macros I added to deal with packed struct member address
> warnings or disabling certain warnings (-fno-strict-aliasing,
> no-address-of-packed-member):
>
>-
>
> https://github.com/cloudius-systems/osv/commit/2ead349dc560a02b412154664420cf1ac0c00f01
>-
>
> https://github.com/cloudius-systems/osv/commit/cef7d8e2403cf8f5f96b38fb7fe5a8e78683b657
>-
>
> https://github.com/cloudius-systems/osv/commit/87522701c4d0844a568c762e675aca9ce27e
>
> If anyone could review those it would be great.
>
> I was able to compile and run the unit tests  (*all pass!*) with IPV6
> enabled (did not test when disabled) on Ubuntu 19.10 with gcc 9.2. I also
> stress-tested a little bit the networking layer with httpserver apps like
> golang-httpserver and rust-httpserver as well as with iperf3. It all seems
> to work. I did not really test any IPV6 scenarios yet (except for what the
> new unit tests that Charles added do). *I am not very familiar with the
> setup with QEMU, ipv6 itself so that is where I am asking for help to test!*
>
> I have also noticed that based on requests per second measured with apache
> bench and iperf3 the ipv6 branch seems to be 3-5% slower than master (ipv4
> traffic but with ipv6 code enabled). But this is just the observation, not
> a hard measurement. But again code seems to work reliably and correctly for
> what my testing is worth.
>
> Finally looking at the Spirent fork (https://github.com/SpirentOrion/osv)
> I think they have made some more changes to the networking code after those
> patches were submitted. It would be nice to bring them over.
>
> Waldek
>
> PS. Some code statistics:
>
>- 38K new lines of code (wc -l bsd/sys/netinet6/*)
>- the loader-stripped.elf binary (kernel) size increases by ~270K with
>IPV6 enabled; I think it is worth price to pay given the functionality
>added (plus we have a witch to turn it on/off); recently by removing
>boost-programs options and replacing with hand-written equivalent let us
>save around 300-500K; so nice exchange!
>
> --
> You received this message because you are subscribed to the Google Groups
> "OSv Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to osv-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/osv-dev/CAL9cFfNNGgXKBkkQKfx%3D7LDz%3DyqG5iR6Um2n5sHWvEhZAb7VrA%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" 

Re: [osv-dev] Fedora 30/31 and Ubuntu 19.10

[Dor Laor]

I built OSv on Fedora 31, worked just fine I had to do this tiny thing:

dorlaor@dorpc osv]$ git diff
diff --git a/scripts/setup.py b/scripts/setup.py
index ce02b5d8..7412bb51 100755
--- a/scripts/setup.py
+++ b/scripts/setup.py
@@ -99,7 +99,15 @@ class Fedora(object):
 ec2_post_install = None
 version = '29'

-versions = [Fedora_25, Fedora_26, Fedora_27, Fedora_28, Fedora_29]
+class Fedora_31(object):
+packages = ['java-1.8.0-openjdk', 'python2-requests',
'openssl-devel', 'lua-5.3.*', 'lua-devel-5.3.*']
+ec2_packages = []
+test_packages = []
+ec2_post_install = None
+version = '31'
+
+
+versions = [Fedora_25, Fedora_26, Fedora_27, Fedora_28, Fedora_29,
Fedora_31]

 class RHELbased(Fedora):
 name = ['Scientific Linux', 'NauLinux', 'CentOS Linux', 'Red Hat
Enterprise Linux', 'Oracle Linux']

On Tue, Nov 26, 2019 at 5:52 AM Nadav Har'El  wrote:

> It seems fine on Fedora 30 (I seem to remember there were some specific
> modules that had problems because of the Boost mess, but not the tests). I
> didn't move to Fedora 31 yet. (I should).
>
>
> On Tue, Nov 26, 2019 at 3:39 PM Waldek Kozaczuk 
> wrote:
>
>> Has anybody tried to build and run OSv on any of those distributions? I
>> think per #1040 the code should build and all unit tests should pass on
>> Fedora 30 (I tested it on my other old laptop with that system).
>>
>> Regards,
>> Waldek
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "OSv Development" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to osv-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/osv-dev/8432b433-4658-44ce-889c-3dceae3842c6%40googlegroups.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "OSv Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to osv-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/osv-dev/CANEVyjv%2BuF0kbV-htA7vDyzG7oiiMPHix4ZnJswYVmKGXZ3TWA%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osv-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osv-dev/CAKUaUn6oUH9fm6tDBwqur4U0r2Pd_fNh1j%3D9dcsMgf_3RKTxQw%40mail.gmail.com.

Re: [osv-dev] Updating http://osv.io/

[Dor Laor]

Done ;)

On Thu, Apr 4, 2019 at 6:16 AM Waldek Kozaczuk  wrote:

> I think I have found the correct repo (based on the latest commit) for the
> blog - https://github.com/osv-io/blog/tree/source - so it is part of the
> same organization as the osv.io site repo. It also looks like the source
> branch (instead of master) is what content gets published from.
>
> Could someone give me access to https://github.com/osv-io/blog?
>
> Thanks,
> Waldek
>
> On Monday, March 25, 2019 at 6:01:45 PM UTC-4, Waldek Kozaczuk wrote:
>>
>> Thanks Dor.
>>
>> From the cursory look the repo for main site -
>> https://github.com/osv-io/osv-io.github.io - seems to correspond to what
>> is on http://osv.io - just by looking at the date of the last commit -
>> Nov, 2015.
>>
>> On other hand the blog seems to be old based on the fact that last commit
>> is from April, 2014 and the latest blog on it -
>> http://blog.osv.io/blog/2017/06/12/serverless-computing-with-OSv/ is 3
>> years newer Which makes me think that possibly the blog site was published
>> from a fork of https://github.com/cloudius-systems/blog.osv.io? Any
>> ideas?
>>
>> On Monday, March 25, 2019 at 1:50:15 PM UTC-4, דור לאור wrote:
>>>
>>> Waldek, I added you as maintainer to osv-io too
>>>
>>> On Mon, Mar 25, 2019 at 1:50 AM Pekka Enberg 
>>> wrote:
>>>
>>>>
>>>>
>>>> On Mon, Mar 25, 2019 at 10:37 AM Nadav Har'El 
>>>> wrote:
>>>>
>>>>>
>>>>> On Mon, Mar 25, 2019 at 8:38 AM Tzach Livyatan 
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> On Mon, Mar 25, 2019 at 8:17 AM Dor Laor  wrote:
>>>>>>
>>>>>>> Waldek, I added you to the blog as admin, a Firecracked blog will be
>>>>>>> awesome.
>>>>>>> I failed to locate the main site itself, Tzach, Pekka, do you
>>>>>>> remember?
>>>>>>>
>>>>>>
>>>>>> This is the repo for the site
>>>>>> https://github.com/cloudius-systems/osv
>>>>>>
>>>>>
>>>>> This is, of course, not the site, but the code
>>>>>
>>>>
>>>> The repository for the OSv home page is here:
>>>>
>>>> https://github.com/osv-io/osv-io.github.io
>>>>
>>>> - Pekka
>>>>
>>> --
> You received this message because you are subscribed to the Google Groups
> "OSv Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to osv-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osv-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [osv-dev] OSv vs Docker vs Linux networking performance comparison

[Dor Laor]

On Wed, Mar 27, 2019 at 6:14 PM Waldek Kozaczuk 
wrote:

>
>
> On Wednesday, March 27, 2019 at 8:24:23 PM UTC-4, דור לאור wrote:
>>
>> On Wed, Mar 27, 2019 at 3:36 PM Waldek Kozaczuk 
>> wrote:
>>
>>> Overall I must say I am not a performance tuning/measuring expert and
>>> clearly have lots of things to learn ;-) BTW can you point me to any
>>> performance setup/procedures/docs that you guys used with OSv?
>>>
>>
>> I tried to look but didn't find much, I do remember with played with all
>> these options when we implemented different
>> scheduling options to deal with spin locks, network performance, etc.
>>
>>
>>> I also feel I have tried to kill too many birds with one stone. Ideally
>>> I should have divided whole thing into 3 categories:
>>> - OSv on firecracker vs QEMU
>>> - OSv vs Docker
>>> - OSv vs Linux guest
>>>
>>> On Tuesday, March 26, 2019 at 8:32:00 PM UTC-4, דור לאור wrote:

 While the performance numbers indicate something, a mac book is a
 horrible environment for performance
 testing. There are effects of other desktop apps, hyperthreading, etc.

>>> Well that is what I have available in my home lab :-) I understand you
>>> are suggesting that apps running on the MacBook might affect and skew the
>>> results. I made sure the only apps open was one or two terminal windows. I
>>> had also mpstat open and most of the time CPUs were idle when tests were
>>> not running. But I get your point that ideally I should use proper headless
>>> server machine. I also get the effect of hyper threading - is there a way
>>> to switch it off in Linux by some kind of boot parameter?
>>>
>>
>> I think it's mainly in the bios. You can pin vcpu to a hyperthread
>> running on a different core and thus eliminate 2 hyperthreads on the same
>> core and get almost the real thing this way
>>
>>
>>>
>>>
>>> Also 1gbps network can be a bottle neck.

>>> Very likely, I have been suspecting same thing.
>>>
>>> Every benchmark case should have a matching performance
 analysis and point to the bottleneck reason - cpu/networking/contect
 switching/locking/filesystem/..

>>> To figure this out I guess I would need to use OSv tracing capability -
>>> https://github.com/cloudius-systems/osv/wiki/Trace-analysis-using-trace.py
>>>
>>>
>>
>> Yes, it has lots of good tactics, using perf and the tracer and also
>> figure out where the cpu time go to.
>>
>>
>>>
>>> Just hyperthread vs a different thread in another core is very
 significant change.
 Need to pin the qemu threads in the host to the right physical threads.

>>> I was not even aware that one can pin to specific CPUs. What parameters
>>> pass to qemu?
>>>
>>
>> I forgot, need to read the manual.. everything is supported.
>>
>>
>>>
 Better to run on a good physical server (like i3.metal on AWS or
 similar, could be smaller but not 2 cores) and
 track all the metrics appropriately. Best is to isolate workloads (and
 make sure they scale linearly too)  in terms of cpu/mem/net/disk and only
 then
 show how a more complex workload performs.

>>> Cannot afford 5$ per hour ;-) Unless I have fully automated test suite.
>>>
>>> My dream would be to have an automated process I could trigger with a
>>> single click of a button that would:
>>> 1) Use cloud formation template to create a VPC with all components of
>>> the test environment.
>>> 2) Automatically start each instance under test and corresponding test
>>> client
>>> 3) Automatically collect all test results (both wrk and possibly tracing
>>> data) and put them somewhere in S3.
>>>
>>> Finally If I had a suite of visualization tools that would generate
>>> whatever graphs I need to analyze. It would save soo much time.
>>> Possibly under hour => then I could pay 5 bucks for it ;-)
>>>
>>> But it takes time to build one ;-)
>>>
>>
>> I think it's possible to continue with your desktop (but try to use
>> Linux) and focus on 1,2 vcpus and analyze each
>> test carefully. Try to realize what's the bottleneck of each test.
>>
> My Mac is configured as a triple-boot machine that can boot to OSX or
> Ubuntu or Windows 10. All the tests were running on bare-metal Linux booted
> MacBook Pro. Do you mean that my test client should also run on Linux
> bare-metal machine?
>

No, the client machine shouldn't matter as long as it generates enough
requests and it seems this is the case


>
>>
>>>
 On Tue, Mar 26, 2019 at 3:29 PM Waldek Kozaczuk 
 wrote:

> Last week I spent some time investigating OSv performance and
> comparing it to Docker and Linux guests. To that end I adopted
> "unikernels-v-containers"' repo by Tom Goethals and extended it with 2 new
> apps (Rust and Node.js) and new scripts to build and deploy OSv apps on
> QEMU/KVM - https://github.com/wkozaczuk/unikernels-v-containers. So
> as you can see my focus was on OSv on QEMU/KVM and firecracker vs Linux on
> firecracker vs Docker whereas Tom's paper 

Re: [osv-dev] OSv vs Docker vs Linux networking performance comparison

[Dor Laor]

On Wed, Mar 27, 2019 at 3:36 PM Waldek Kozaczuk 
wrote:

> Overall I must say I am not a performance tuning/measuring expert and
> clearly have lots of things to learn ;-) BTW can you point me to any
> performance setup/procedures/docs that you guys used with OSv?
>

I tried to look but didn't find much, I do remember with played with all
these options when we implemented different
scheduling options to deal with spin locks, network performance, etc.


> I also feel I have tried to kill too many birds with one stone. Ideally I
> should have divided whole thing into 3 categories:
> - OSv on firecracker vs QEMU
> - OSv vs Docker
> - OSv vs Linux guest
>
> On Tuesday, March 26, 2019 at 8:32:00 PM UTC-4, דור לאור wrote:
>>
>> While the performance numbers indicate something, a mac book is a
>> horrible environment for performance
>> testing. There are effects of other desktop apps, hyperthreading, etc.
>>
> Well that is what I have available in my home lab :-) I understand you are
> suggesting that apps running on the MacBook might affect and skew the
> results. I made sure the only apps open was one or two terminal windows. I
> had also mpstat open and most of the time CPUs were idle when tests were
> not running. But I get your point that ideally I should use proper headless
> server machine. I also get the effect of hyper threading - is there a way
> to switch it off in Linux by some kind of boot parameter?
>

I think it's mainly in the bios. You can pin vcpu to a hyperthread running
on a different core and thus eliminate 2 hyperthreads on the same core and
get almost the real thing this way


>
>
> Also 1gbps network can be a bottle neck.
>>
> Very likely, I have been suspecting same thing.
>
> Every benchmark case should have a matching performance
>> analysis and point to the bottleneck reason - cpu/networking/contect
>> switching/locking/filesystem/..
>>
> To figure this out I guess I would need to use OSv tracing capability -
> https://github.com/cloudius-systems/osv/wiki/Trace-analysis-using-trace.py
>
>

Yes, it has lots of good tactics, using perf and the tracer and also figure
out where the cpu time go to.


>
> Just hyperthread vs a different thread in another core is very significant
>> change.
>> Need to pin the qemu threads in the host to the right physical threads.
>>
> I was not even aware that one can pin to specific CPUs. What parameters
> pass to qemu?
>

I forgot, need to read the manual.. everything is supported.


>
>> Better to run on a good physical server (like i3.metal on AWS or similar,
>> could be smaller but not 2 cores) and
>> track all the metrics appropriately. Best is to isolate workloads (and
>> make sure they scale linearly too)  in terms of cpu/mem/net/disk and only
>> then
>> show how a more complex workload performs.
>>
> Cannot afford 5$ per hour ;-) Unless I have fully automated test suite.
>
> My dream would be to have an automated process I could trigger with a
> single click of a button that would:
> 1) Use cloud formation template to create a VPC with all components of the
> test environment.
> 2) Automatically start each instance under test and corresponding test
> client
> 3) Automatically collect all test results (both wrk and possibly tracing
> data) and put them somewhere in S3.
>
> Finally If I had a suite of visualization tools that would generate
> whatever graphs I need to analyze. It would save soo much time.
> Possibly under hour => then I could pay 5 bucks for it ;-)
>
> But it takes time to build one ;-)
>

I think it's possible to continue with your desktop (but try to use Linux)
and focus on 1,2 vcpus and analyze each
test carefully. Try to realize what's the bottleneck of each test.


>
>> On Tue, Mar 26, 2019 at 3:29 PM Waldek Kozaczuk 
>> wrote:
>>
>>> Last week I spent some time investigating OSv performance and comparing
>>> it to Docker and Linux guests. To that end I adopted
>>> "unikernels-v-containers"' repo by Tom Goethals and extended it with 2 new
>>> apps (Rust and Node.js) and new scripts to build and deploy OSv apps on
>>> QEMU/KVM - https://github.com/wkozaczuk/unikernels-v-containers. So as
>>> you can see my focus was on OSv on QEMU/KVM and firecracker vs Linux on
>>> firecracker vs Docker whereas Tom's paper was comparing OSv on Xen vs
>>> Docker (details of discussion around it and the link to the paper you can
>>> find here - https://groups.google.com/forum/#!topic/osv-dev/lhkqFfzbHwk
>>> ).
>>>
>>> Specifically I wanted to compare networking performance in terms of
>>> number of REST API requests per second processed by a typical microservice
>>> app implemented in Rust (built using hyper), Golang and Java (built using
>>> vertx.io) and running on following:
>>>
>>>- OSv on QEMU/KVM
>>>- OSv on firecracker
>>>- Docker container
>>>- Linux on firecracker
>>>
>>> Each app in essence implements simple todo REST api returning a json
>>> payload 100-200 characters long (for example see here Java one -
>>> 

Re: [osv-dev] OSv vs Docker vs Linux networking performance comparison

[Dor Laor]

On Wed, Mar 27, 2019 at 3:59 AM Matias Vara  wrote:

> Hello Waldek,
>
> The experiments are very interesting. I showed something similar at
> OSSumit'18 (see
> https://github.com/torokernel/papers/blob/master/OSSummit18.pdf). What I
> do not understand from your conclusions is why do you expect that OSv
> scales with the number of cores? Maybe I did not understand something.
>

Because it's designed to scale and scale most of the time with a proper
good setup.
There are some times issues related to scheduling with spin locks that
effect scaling a lot but OSv
should handle them well, in the past we've done good amount of tests and
shared results.


>
> Matias
>
> El mar., 26 mar. 2019 a las 23:29, Waldek Kozaczuk ()
> escribió:
>
>> Last week I spent some time investigating OSv performance and comparing
>> it to Docker and Linux guests. To that end I adopted
>> "unikernels-v-containers"' repo by Tom Goethals and extended it with 2 new
>> apps (Rust and Node.js) and new scripts to build and deploy OSv apps on
>> QEMU/KVM - https://github.com/wkozaczuk/unikernels-v-containers. So as
>> you can see my focus was on OSv on QEMU/KVM and firecracker vs Linux on
>> firecracker vs Docker whereas Tom's paper was comparing OSv on Xen vs
>> Docker (details of discussion around it and the link to the paper you can
>> find here - https://groups.google.com/forum/#!topic/osv-dev/lhkqFfzbHwk).
>>
>> Specifically I wanted to compare networking performance in terms of
>> number of REST API requests per second processed by a typical microservice
>> app implemented in Rust (built using hyper), Golang and Java (built using
>> vertx.io) and running on following:
>>
>>- OSv on QEMU/KVM
>>- OSv on firecracker
>>- Docker container
>>- Linux on firecracker
>>
>> Each app in essence implements simple todo REST api returning a json
>> payload 100-200 characters long (for example see here Java one -
>> https://github.com/wkozaczuk/unikernels-v-containers/blob/master/restapi/java-osv/src/main/java/rest/SimpleREST.java).
>> The source code of all apps is under this subtree -
>> https://github.com/wkozaczuk/unikernels-v-containers/blob/master/restapi.
>> One thing to not was that each request would return always the same payload
>> (I wonder if that may cause the response gets cached and affects results).
>>
>> The test setup looked like this:
>>
>> *Host:*
>>
>>- MacBook Pro with Intel i7 4 cores CPU with hyperthreading (8 cpus
>>reported by lscpu) with 16GB of RAM with Ubuntu 18.10 on it
>>- firecracker 0.15.0
>>- QEMU 2.12.0
>>
>>
>> *Client machine:*
>>
>>- similar to the one above with wrk as a test client firing requests
>>using 10 threads and 100 open connections for 30 seconds in 3 series one 
>> by
>>one (please see this test script -
>>
>> https://github.com/wkozaczuk/unikernels-v-containers/blob/master/test-restapi-with-wrk.sh
>>).
>>- wrk by default uses Keep-Alive for http connections so TCP
>>handshake is minimal
>>
>> The host and client machine were connected directly to 1 GBit ethernet
>> switch and host exposed guest IP using a bridged TAP nic (please see the
>> script used -
>> https://raw.githubusercontent.com/cloudius-systems/osv/master/scripts/setup-external-bridge.sh
>> ).
>>
>> You can find scripts to start applications on OSv and docker here -
>> https://github.com/wkozaczuk/unikernels-v-containers (run* scripts).
>> Please note --cpu-set parameter used in docker script to limit number of
>> CPUs.
>>
>> You can find detailed results under
>> https://github.com/wkozaczuk/unikernels-v-containers/tree/master/test_results/remote
>> .
>>
>> Here are just requests per seconds numbers (full example -
>> https://raw.githubusercontent.com/wkozaczuk/unikernels-v-containers/master/test_results/remote/docker/rust_docker_4_cpu.wrk
>> )
>>
>> OSv on QEMU
>> *Golang*
>> *1 CPU*
>> Requests/sec:  24313.06
>> Requests/sec:  23874.74
>> Requests/sec:  23300.26
>>
>> *2 CPUs*
>> Requests/sec:  37089.26
>> Requests/sec:  35475.22
>> Requests/sec:  33581.87
>>
>> *4 CPUs*
>> Requests/sec:  42747.11
>> Requests/sec:  43057.99
>> Requests/sec:  42346.27
>>
>> *Java*
>> *1 CPU*
>> Requests/sec:  41049.41
>> Requests/sec:  43622.81
>> Requests/sec:  44777.60
>> *2 CPUs*
>> Requests/sec:  46245.95
>> Requests/sec:  45746.48
>> Requests/sec:  46224.42
>> *4 CPUs*
>> Requests/sec:  48128.33
>> Requests/sec:  45467.53
>> Requests/sec:  45776.45
>>
>> *Rust*
>>
>> *1 CPU*
>> Requests/sec:  43455.34
>> Requests/sec:  43927.73
>> Requests/sec:  41100.07
>>
>> *2 CPUs*
>> Requests/sec:  49120.31
>> Requests/sec:  49298.28
>> Requests/sec:  48076.98
>> *4 CPUs*
>> Requests/sec:  51477.57
>> Requests/sec:  51587.92
>> Requests/sec:  49118.68
>>
>> OSv on firecracker
>> *Golang*
>>
>> *1 cpu*
>> Requests/sec:  16721.56
>> Requests/sec:  16422.33
>> Requests/sec:  16540.24
>>
>> *2 cpus*
>> Requests/sec:  28538.35
>> Requests/sec:  26676.68
>> Requests/sec:  28100.00
>>
>> *4 cpus*
>> 

Re: [osv-dev] OSv vs Docker vs Linux networking performance comparison

[Dor Laor]

While the performance numbers indicate something, a mac book is a horrible
environment for performance
testing. There are effects of other desktop apps, hyperthreading, etc.
Also 1gbps network can be a bottle neck. Every benchmark case should have a
matching performance
analysis and point to the bottleneck reason - cpu/networking/contect
switching/locking/filesystem/..
Just hyperthread vs a different thread in another core is very significant
change.
Need to pin the qemu threads in the host to the right physical threads.

Better to run on a good physical server (like i3.metal on AWS or similar,
could be smaller but not 2 cores) and
track all the metrics appropriately. Best is to isolate workloads (and make
sure they scale linearly too)  in terms of cpu/mem/net/disk and only then
show how a more complex workload performs.

On Tue, Mar 26, 2019 at 3:29 PM Waldek Kozaczuk 
wrote:

> Last week I spent some time investigating OSv performance and comparing it
> to Docker and Linux guests. To that end I adopted
> "unikernels-v-containers"' repo by Tom Goethals and extended it with 2 new
> apps (Rust and Node.js) and new scripts to build and deploy OSv apps on
> QEMU/KVM - https://github.com/wkozaczuk/unikernels-v-containers. So as
> you can see my focus was on OSv on QEMU/KVM and firecracker vs Linux on
> firecracker vs Docker whereas Tom's paper was comparing OSv on Xen vs
> Docker (details of discussion around it and the link to the paper you can
> find here - https://groups.google.com/forum/#!topic/osv-dev/lhkqFfzbHwk).
>
> Specifically I wanted to compare networking performance in terms of number
> of REST API requests per second processed by a typical microservice app
> implemented in Rust (built using hyper), Golang and Java (built using
> vertx.io) and running on following:
>
>- OSv on QEMU/KVM
>- OSv on firecracker
>- Docker container
>- Linux on firecracker
>
> Each app in essence implements simple todo REST api returning a json
> payload 100-200 characters long (for example see here Java one -
> https://github.com/wkozaczuk/unikernels-v-containers/blob/master/restapi/java-osv/src/main/java/rest/SimpleREST.java).
> The source code of all apps is under this subtree -
> https://github.com/wkozaczuk/unikernels-v-containers/blob/master/restapi.
> One thing to not was that each request would return always the same payload
> (I wonder if that may cause the response gets cached and affects results).
>
> The test setup looked like this:
>
> *Host:*
>
>- MacBook Pro with Intel i7 4 cores CPU with hyperthreading (8 cpus
>reported by lscpu) with 16GB of RAM with Ubuntu 18.10 on it
>- firecracker 0.15.0
>- QEMU 2.12.0
>
>
> *Client machine:*
>
>- similar to the one above with wrk as a test client firing requests
>using 10 threads and 100 open connections for 30 seconds in 3 series one by
>one (please see this test script -
>
> https://github.com/wkozaczuk/unikernels-v-containers/blob/master/test-restapi-with-wrk.sh
>).
>- wrk by default uses Keep-Alive for http connections so TCP handshake
>is minimal
>
> The host and client machine were connected directly to 1 GBit ethernet
> switch and host exposed guest IP using a bridged TAP nic (please see the
> script used -
> https://raw.githubusercontent.com/cloudius-systems/osv/master/scripts/setup-external-bridge.sh
> ).
>
> You can find scripts to start applications on OSv and docker here -
> https://github.com/wkozaczuk/unikernels-v-containers (run* scripts).
> Please note --cpu-set parameter used in docker script to limit number of
> CPUs.
>
> You can find detailed results under
> https://github.com/wkozaczuk/unikernels-v-containers/tree/master/test_results/remote
> .
>
> Here are just requests per seconds numbers (full example -
> https://raw.githubusercontent.com/wkozaczuk/unikernels-v-containers/master/test_results/remote/docker/rust_docker_4_cpu.wrk
> )
>
> OSv on QEMU
> *Golang*
> *1 CPU*
> Requests/sec:  24313.06
> Requests/sec:  23874.74
> Requests/sec:  23300.26
>
> *2 CPUs*
> Requests/sec:  37089.26
> Requests/sec:  35475.22
> Requests/sec:  33581.87
>
> *4 CPUs*
> Requests/sec:  42747.11
> Requests/sec:  43057.99
> Requests/sec:  42346.27
>
> *Java*
> *1 CPU*
> Requests/sec:  41049.41
> Requests/sec:  43622.81
> Requests/sec:  44777.60
> *2 CPUs*
> Requests/sec:  46245.95
> Requests/sec:  45746.48
> Requests/sec:  46224.42
> *4 CPUs*
> Requests/sec:  48128.33
> Requests/sec:  45467.53
> Requests/sec:  45776.45
>
> *Rust*
>
> *1 CPU*
> Requests/sec:  43455.34
> Requests/sec:  43927.73
> Requests/sec:  41100.07
>
> *2 CPUs*
> Requests/sec:  49120.31
> Requests/sec:  49298.28
> Requests/sec:  48076.98
> *4 CPUs*
> Requests/sec:  51477.57
> Requests/sec:  51587.92
> Requests/sec:  49118.68
>
> OSv on firecracker
> *Golang*
>
> *1 cpu*
> Requests/sec:  16721.56
> Requests/sec:  16422.33
> Requests/sec:  16540.24
>
> *2 cpus*
> Requests/sec:  28538.35
> Requests/sec:  26676.68
> Requests/sec:  28100.00
>
> 

Re: [osv-dev] Updating http://osv.io/

[Dor Laor]

Waldek, I added you as maintainer to osv-io too

On Mon, Mar 25, 2019 at 1:50 AM Pekka Enberg  wrote:

>
>
> On Mon, Mar 25, 2019 at 10:37 AM Nadav Har'El  wrote:
>
>>
>> On Mon, Mar 25, 2019 at 8:38 AM Tzach Livyatan 
>> wrote:
>>
>>>
>>> On Mon, Mar 25, 2019 at 8:17 AM Dor Laor  wrote:
>>>
>>>> Waldek, I added you to the blog as admin, a Firecracked blog will be
>>>> awesome.
>>>> I failed to locate the main site itself, Tzach, Pekka, do you remember?
>>>>
>>>
>>> This is the repo for the site
>>> https://github.com/cloudius-systems/osv
>>>
>>
>> This is, of course, not the site, but the code
>>
>
> The repository for the OSv home page is here:
>
> https://github.com/osv-io/osv-io.github.io
>
> - Pekka
>

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osv-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [osv-dev] Capstan

[Dor Laor]

IMHO the original Capstan git is the best but you're most welcome to host
it in yours too

On Sun, Mar 24, 2019 at 6:58 AM Waldek Kozaczuk 
wrote:

> Now that we have new updated message in the old capstan repo -
> https://github.com/cloudius-systems/capstan  (thanks Pekka) - we are all
> good :-) This obviously solved one problem but there is other one - new
> Mikelangelo capstan points to the S3 repo -
> https://mikelangelo-capstan.s3.amazonaws.com/ - which is no longer
> maintained and has old artifacts - kernel and old mpm files. What is worse
> that old kernel (loader.img) and new artifacts published on github are not
> compatible due to a breaking change we made to OSv app API in order to
> support golang - see other email exchange with Rob. And I think it causes a
> lot of frustration among any new potential OSv and capstan users.
>
> One alternative to solve this problem would be to make new capstan work
> with artifacts published on github. I even have a "work-in-progress" branch
> - https://github.com/wkozaczuk/capstan/tree/github_repo that supports it.
> I might have some time to finish it. I hope that Miha from XLab will be
> kind again to review my pull request and publish new version of capstan.
>
> Does anybody have other better ideas?
>
> Waldek
>
> --
> You received this message because you are subscribed to the Google Groups
> "OSv Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to osv-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osv-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [osv-dev] Updating http://osv.io/

[Dor Laor]

Waldek, I added you to the blog as admin, a Firecracked blog will be
awesome.
I failed to locate the main site itself, Tzach, Pekka, do you remember?

On Sun, Mar 24, 2019 at 6:13 AM Waldek Kozaczuk 
wrote:

> Hi,
>
> I meant to send an email about it for a long time ;-) Anyway I wanted to
> point out that OSv website (http://osv.io/) is a little dated and has
> somewhat outdated information. But most of the information still very
> spot-on and useful. I actually spent some time browsing through it and I
> must say it has quite reasonable look and feel to it and is even responsive
> on small factor devices (aka bootstrap enabled). The bad part of it is that
> is still hosts very old (> 3 years) image artifacts -
> http://osv.io/downloads/. Could someone delete those?
>
> I also have more general request: does anybody know how does this website
> is hosted and how gets published? Is it using Jekyll? Can we count on the
> domain osv.io to stay? Should we rather move to github.io hosted website
> scenario - https://pages.github.com/ and
> https://help.github.com/en/articles/using-jekyll-as-a-static-site-generator-with-github-pages
> for blogging?
>
> Would it be possible to get hands on this content (this -
> https://github.com/cloudius-systems/cloudius-systems.github.io - looks
> empty)? Is this possibly a github project with static content that we could
> get access to? Could we create with a copy of it? I am actually pretty
> versed into HTML, CSS, JS so I could tweak things or two but I need access.
>
> I was actually also thinking about writing an article about Firecracker
> and OSv. Ideally I would post on our blog - http://blog.osv.io/. Is this
> possible?
>
> Thanks in advance for your answers,
> Waldek
>
> --
> You received this message because you are subscribed to the Google Groups
> "OSv Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to osv-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osv-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Removing assigned_virtio (--assign-net option) - give feedback if you rely on it!!!

[Dor Laor]

On Wed, Jan 16, 2019 at 8:57 AM Waldek Kozaczuk  wrote:
>
> One of the virtio devices supported by OSv is assigned_virtio. To best of my 
> knowledge (based on what Nadav wrote) this driver has been invented in order 
> to better integrate OSv with seastar (see #ifdef HAVE_OSV in 
> https://github.com/scylladb/seastar/blob/e3466851e047ec7494c983b4f316e1a4464a4945/src/net/virtio.cc#L56).
>
> I am not sure if anybody is relying on this feature. If you do then please 
> let me know. Otherwise I am planning to send a patch that will remove this 
> functionality from OSv. Doing so will allow to significantly simplify the 
> patch that refactors OSv virtio stack in order to support modern virtio PCI 
> devices and mmio devices (see 
> https://groups.google.com/d/msg/osv-dev/NIDG5zLLv0A/bE69BwI7EwAJ for 
> details). At this point I do not even have a way to test this patch without 
> seastar. So I am thinking it is simply dead code that can be removed (the 
> less code the better).
>
> Anybody who relies on it please shout otherwise I will be sending a patch to 
> remove this feature.

I think you can safely remove it unless we hear about a user who
object with good arguments.


>
> Regards,
> Waldek
>
> --
> You received this message because you are subscribed to the Google Groups 
> "OSv Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to osv-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osv-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [RFC] Support firecracker

[Dor Laor]

On Sun, Jan 6, 2019 at 5:49 PM Asias He  wrote:

>
>
> On Sun, Jan 6, 2019 at 11:32 AM Waldek Kozaczuk 
> wrote:
>
>>
>>
>> On Saturday, January 5, 2019 at 4:09:23 AM UTC-5, דור לאור wrote:
>>>
>>> Great stuff Waldek! Is unix socket the normal way to pass parameters for
>>> Firecracker?
>>>
>> I think so. There is also experimental vsock interface but I am not
>> familiar with it and not sure what purpose of it would be (
>> https://github.com/firecracker-microvm/firecracker/issues/650).
>>
>
> Vsock was added for easier guest host communication with zero
> configuration (I happen to the author of the vsock kernel module).  In
> theory, they can use vsock for anything that a socket is useful between
> host and guest.
> Btw, there are some work to implement nfs over vsock.
>

Good point, this way they can preboot OSv and run the app with the vsock
control (although any guest can
be controlled this way too)


>
>
>>
>>> How's the boot speed vs Qemu?
>>>
>> I have posted some numbers in my other email to the group but here are
>> some more details.
>>
>> First of all my numbers come from running tests on my 5-years old MacBook
>> pro that I have been using for all my OSv development in last three years.
>> It is 4-core 2.3 GHz i7 machine. Not sure how it compares to newer models
>> but given Moore's law does not work any more it might be still pretty fast.
>>
>> Architecture:x86_64
>> CPU op-mode(s):  32-bit, 64-bit
>> Byte Order:  Little Endian
>> CPU(s):  8
>> On-line CPU(s) list: 0-7
>> Thread(s) per core:  2
>> Core(s) per socket:  4
>> Socket(s):   1
>> NUMA node(s):1
>> Vendor ID:   GenuineIntel
>> CPU family:  6
>> Model:   70
>> Model name:  Intel(R) Core(TM) i7-4850HQ CPU @ 2.30GHz
>> Stepping:1
>> CPU MHz: 898.037
>> CPU max MHz: 3500.
>> CPU min MHz: 800.
>> BogoMIPS:4589.68
>> Virtualization:  VT-x
>> L1d cache:   32K
>> L1i cache:   32K
>> L2 cache:256K
>> L3 cache:6144K
>> L4 cache:131072K
>>
>> Additionally firecracker startup/configuration is more fine-grained than
>> QEMU which does everything in one shot (start VMM process, configure
>> resources, start guest, etc). With firecracker it is broken down like
>> follows:
>>
>>1. Start VMM process which listen on socket for API calls (I have not
>>measured it but seems very fast).
>>2. Make API call to:
>>   - create instance that specified number of vCPUs, memory and
>>   kernel loader file path
>>   - configure block device
>>   - configure networking device
>>   - all these calls seem to take less than 1ms and can be executed
>>   in any order it seems
>>3. Make API call to start instance that eventually starts guest
>>
>> So here are some log snippets (2,3) and OSv bootchart from running
>> native-example rofs image (no networking):
>>
>> Add block device:
>> 2019-01-05T20:21:44.*096*617431 [anonymous-instance:INFO:api_server/src/
>> http_service.rs:599] The API server received a synchronous Put request
>> on "/drives/rootfs" with body "{n "drive_id": "rootfs",n "path_on_host":
>> "/home/wkozaczuk/projects/osv/build/release/usr.rofs",n "is_root_device":
>> false,n "is_read_only": falsen }".
>> 2019-01-05T20:21:44.*096*659174 [anonymous-instance:INFO:api_server/src/
>> http_service.rs:565] The synchronous Put request on "/drives/rootfs"
>> with body "{n "drive_id": "rootfs",n "path_on_host":
>> "/home/wkozaczuk/projects/osv/build/release/usr.rofs",n "is_root_device":
>> false,n "is_read_only": falsen }" was executed successfully. Status code:
>> 204 No Content.
>>
>> Create instance:
>> 2019-01-05T20:21:44.*1085*43339 [anonymous-instance:INFO:api_server/src/
>> http_service.rs:599] The API server received a synchronous Put request
>> on "/boot-source" with body "{n "kernel_image_path":
>> "/home/wkozaczuk/projects/waldek-osv/build/release/loader-stripped.elf",n
>> "boot_args": "--bootchart /hello"n }".
>> 2019-01-05T20:21:44.*108*584295 [anonymous-instance:INFO:api_server/src/
>> http_service.rs:565] The synchronous Put request on "/boot-source" with
>> body "{n "kernel_image_path":
>> "/home/wkozaczuk/projects/waldek-osv/build/release/loader-stripped.elf",n
>> "boot_args": "--bootchart /hello"n }" was executed successfully. Status
>> code: 204 No Content.
>>
>> Start instance that starts guest and terminates the process eventually:
>> 2019-01-05T20:21:44.119820357 [anonymous-instance:INFO:api_server/src/
>> http_service.rs:599] The API server received a synchronous Put request
>> on "/actions" with body "{n "action_type": "InstanceStart"n }".
>> 2019-01-05T20:21:44.119837722 [anonymous-instance:INFO:vmm/src/
>> lib.rs:1104] VMM received instance start command
>> 2019-01-05T20:21:44.119903817 [anonymous-instance:INFO:vmm/src/
>> vstate.rs:97] Guest memory starts at 7faddec0
>>
>> 

Re: [RFC] Support firecracker

[Dor Laor]

Great stuff Waldek! Is unix socket the normal way to pass parameters for
Firecracker?

How's the boot speed vs Qemu?

On Sat, Jan 5, 2019 at 12:03 AM Pekka Enberg  wrote:

>
>
> On Sat, Jan 5, 2019 at 9:58 AM Pekka Enberg  wrote:
>
>>
>>
>> On Sat, Jan 5, 2019 at 9:43 AM Waldek Kozaczuk 
>> wrote:
>>
>>> Indeed I have come across some incompatibility issues. Mostly around
>>> configuration but nothing very fundamental. You can see in some of my
>>> comments.
>>>
>>
>> Right, I missed the comments because the diff is somewhat large. ;-)
>>
>> I would suggest to do Firecracker support in the following (largely
>> independent) steps:
>>
>> - Add support for modern virtio interfaces. Linux has a split driver base
>> model here, which we could also follow. I.e., have separate VirtioModern
>> and VirtioLegacy base classes that encapsulate the differences.
>>
>
> Btw, this can be also tested with QEMU by passing the "disable-modern=off"
> and "disable-legacy=on" options to the "-device" option that defines the
> virtio devices.
>
> - Pekka
>
>> --
> You received this message because you are subscribed to the Google Groups
> "OSv Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to osv-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osv-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How Can I Help?

[Dor Laor]

Hi Mike,

You're all welcome! There are lots of open issues on the githubs of the
various projects,
you're welcome to take a stab on them.
Best,
Dor

On Sun, Nov 11, 2018 at 10:44 AM Mike Kelp  wrote:

> Hi there,
>
> First off, thanks for trying to accomplish, and sharing, such an important
> project! I know low-level systems projects like this are long, hard
> commitments; and not always given the due appreciation. Thank you for doing
> it.
>
> I've been tracking OSv for a while now, hoping to use it with java
> applications we build and I'm now getting more opportunities to do so. As I
> get more familiar with it, I'll hopefully be much more useful, but for the
> time being I wanted to see that best ways I could support the project.
>
> I have what I'll call an intermediate understanding of OS architecture (I
> took Systems Programming / OS architecture courses, etc and have deeply
> researched how the OSes we use work including virtualization), but haven't
> done any OS development at all or C development in quite a while so it will
> take time to build that back up again. With that in mind, I don't expect to
> be as useful in code for now as I would be in other projects, but
> meanwhile, I would like to support the project.
>
> So, how can I help? Where I can find time, I'm willing to try anything
> that honestly helps you all.
>
> Some random examples to get thoughts going:
>
>- Cleaning up issues or any janitorial task there
>- Automating processes (especially with Java)
>- Documentation cleanup
>
> Let me know what would best improve the productivity as a whole and I will
> try to jump in.
>
> Cheers,
> Mike
>
> --
> You received this message because you are subscribed to the Google Groups
> "OSv Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to osv-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osv-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: OSv time drifting when running under KVM

[Dor Laor]

Need to look at the guest log and the restapi

On Fri, Sep 14, 2018, 15:53 Rick Payne  wrote:

> On Fri, 2018-09-14 at 12:12 -0700, Waldek Kozaczuk wrote:
> > Stupid question: are you sure the KVM accellarion is actually enabled
> > and kvm-clock actually used? If not OSv would fall back to hpet which
> > we know we have some problems with.
>
> My turn for a stupid question - how would I know?
>
> I do 'virsh edit ...' to edit the XML and the first line is:
>
> 
>
> so I assumed its kvm based. I tried to ensure that kvmclock was used by
> changing the timer settings to:
>
>   
> 
>   
>
> Cheers,
> Rick
>
> --
> You received this message because you are subscribed to the Google Groups
> "OSv Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to osv-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osv-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Library unikernel or modularization of OSv kernel

[Dor Laor]

On Sat, May 5, 2018 at 9:48 AM, Waldek Kozaczuk 
wrote:

> What if there was a way early into the booting process to load specific
> features of OSv, that right now are linked in as part of kernel, as
> libraries? For example if we mounted ROFS as early and possible we could
> load other elements of the logic (configuration, ZFS, boost program options
> library, dhcp, etc) on demand and only as needed. Same way even some
> drivers could be loaded on demand later.
>
> Why would it be beneficial?
>

You can gain it all by preparing the right image ahead of time, so you'll
only have the features/setup you wish before boot.

What's good about your approach is that you can boot a generic image ahead
of time and only customize it once
you actually need to use it (when the first packet arrives) and thus save
the boot time


>
>- OSv kernel would be smaller and load even faster
>- OSv kernel can be modularized and therefore better tailored for
>specific hypervisor or application needs
>
> What do you think?
>
> Waldek
>
> --
> You received this message because you are subscribed to the Google Groups
> "OSv Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to osv-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osv-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Releasing OSv

[Dor Laor]

IIRC we agreed to release a 0.25 few months ago. No problem to go
back to a regular cadence of releases. Waldek, we'll need you as a driving
force.

On Sun, Feb 25, 2018 at 3:15 PM, Nadav Har'El  wrote:

>
> On Sun, Feb 25, 2018 at 8:45 PM, Waldek Kozaczuk 
> wrote:
>
>> I would like to publish new release of OSv. The last official one was
>> 0.24 and published on Oct 30, 2015 (a little over 2 years). I have never
>> released OSv so any input and suggestions are very welcome especially from
>> those that did it in the past.
>>
>
> I agree. The antique release is just a trap for new users, who might be
> tempted to use that version. So we should either make a new release, or
> decide we don't have any releases at all and delete the links to old
> releases.
>
> I think it would be nice to have a new release, if you're up to it.
>
>
>>
>> There is an existing wiki page that documents how to publish new release
>> - https://github.com/cloudius-systems/osv/wiki/OSv-Release-Procedure.
>> However I think most of the steps do not apply anymore.
>>
>
> I agree, and I think then whenever we decide what should apply going
> forward, we should change that wiki page.
>
>
>> I think I should follow standard Github release procedure -
>> https://help.github.com/articles/creating-releases/.
>>
>
> I'm not sure if it's relevant either - you can use git commands to make
> tags. And we should use ones similar to those we used in previous releases.
>
>
>>
>> I would also like to take advantage of ability to upload binaries
>> associated with the release. My plan is to build and attach "osv.loader"
>> (aka usr.img) and "osv.bootstrap" mpm file and then let users use
>> mikelangelo capstan in order to build new app packages. The trick is to
>> build it using same or similar tool chain as other capstan packages are
>> built. I am planning to use same or similar docker file as here -
>> https://github.com/mikelangelo-project/capstan-packages in order to
>> avoid any incompatibility issues as described here -
>> https://www.mikelangelo-project.eu/2017/08/the-art-of-prep
>> aring-osv-packages/. I think it is important to use same host system
>> (ubuntu 14), specific gcc and possibly specific version of other artifacts
>> to make sure usr.img is compatible.
>>
>
> Good luck with that. I think it may take a bit of experimentation to get
> the version compatibility issues worked around (we can also fix many of
> these issues at OSv itself, but this is orthogonal to the release issues).
> But I have to wonder, shouldn't the compiled-package repository (for
> Mikelangelo Capstan) and the compiled-kernel be at the same place, and the
> person in charge of this place responsible to compiling them all in the
> same environment? How will it help if we only host the kernel, and someone
> else hosts the applications?
>
>
>>
>>
>> My goal is to make it easier for OSv newcomers to try OSv. I also want to
>> focus on promoting OSv as a deployment platform for stateless services.
>> Therefore I would like to make it easy to build images using runtimes like
>> JVM, node.js, erlang, python, ruby and eventually golang. I would be also
>> nice to make it easy to try apps like redis, nginx, etc.
>>
>> Some outstanding questions:
>>
>>- What should be new release version - 0.50, 0.75?
>>
>> I think 0.5.
>
>
>>
>>- What should be the release notes? I think it would be worth to at
>>least list major new features added since last release.
>>
>>
> We can start digging in "git log" to compile a release notes, when the
> time comes.
> I think so much time has passed, that nobody will remember what 0.24
> contained, anyway :-)
> In any case, the release notes should mention Mikelangelo Capstan and
> explain how to use it, because that is a major new thing which became
> relevant in this release.
>
> Thanks,
> Nadav.
>
> --
> You received this message because you are subscribed to the Google Groups
> "OSv Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to osv-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osv-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: packet capture

[Dor Laor]

You'll just have to change the code in the OS level, check how the modified
memcache works, it hooks exactly in the right location.

On Thu, Dec 7, 2017 at 2:28 AM,  wrote:

> Hi,
>
> is there any special API to do high performance packet capture? Or direct
> access to the network drivers?
> Are PF_PACKET sockets supported?
>
> Thanks,
>
> Aron
>
> --
> You received this message because you are subscribed to the Google Groups
> "OSv Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to osv-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osv-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Slow to upload thousands of tiny files over cpiod

[Dor Laor]

On Fri, Nov 3, 2017 at 8:14 PM, Waldek Kozaczuk 
wrote:

> Miha,
>
> It looks like you are right. When I disabled printing of files names in
> cpiod it made some difference when using QEMU and huge difference when
> using VirtualBox on OSX. With QEMU on average I was able to cut down the
> time from ~ 3 minutes to ~2 minutes and from ~10 minutes to ~ 10 SECONDS
> with VirtualBox when uploading 13,000 tiny files. Please note i have not
> run any tests on Linux yet which I am planning to do next.
>
> Does this mean that in general printing to standard out (over serial
> console?) is slow and should be avoided? And it is extra slow on some
>

Yes, serial console is slow, every character triggers an interrupt and exit
to the hypervisor userspace if not more than one.


> hypervisors/emulators like VirtualBox? Does this have anything with this
> recent patch - https://github.com/cloudius-systems/osv/commit/
> a543b9e6dd8776c43e070ec1b677f2fe1dcbb72e?
>
> Regards,
> Waldek
>
>
> On Friday, November 3, 2017 at 3:40:32 AM UTC-4, miha.ple...@gmail.com
> wrote:
>>
>> Hi Waldek,
>>
>> I think the slowness comes because cpiod reports each file on the stdout.
>> Could you try to comment-out the logging in cpiod and try if it works
>> faster?
>> So if you open two terminals and in the first one run:
>>
>> ```
>> $ capstan run demo --execute "/tools/cpiod.so --prefix /zfs/zfs" -f
>> 1:1
>> ```
>>
>> Then in another terminal run:
>>
>> ```
>> $ capstan package compose-remote localhost
>> ```
>>
>> Capstan will start uploading. But if you look at the first terminal, then
>> you will notice that each file is printed to console, e.g.:
>>
>> ```
>> $ capstan run demo --execute "/tools/cpiod.so --prefix /zfs/zfs" -f
>> 1:1
>> Command line will be set based on --run parameter
>> Created instance: demo
>> Setting cmdline: /tools/cpiod.so --prefix /zfs/zfs
>> OSv v0.24-448-g829bf76
>> eth0: 192.168.122.15
>> Waiting for connection from host...
>>
>> Adding /tools/cpiod.so...  # <-
>> --- PROBLEMATIC OUTPUT, SHOULD
>> BE SUPPRESSED
>> Adding /bin...
>> Adding /bin/libnode-4.4.5.so...
>> Adding /run/interpreter...
>> Adding /run/sleep...
>> Adding /server.js...
>> Adding /usr...
>> Adding /zpool.so...
>> Adding /etc...
>> Link /node to /bin/libnode-4.4.5.so ...
>> Adding /run/burek...
>> Adding /run/node...
>> Adding /tmp...
>> Adding /run...
>> Adding /tools...
>> Adding /libzfs.so...
>> Adding /zfs.so...
>> Adding /run/hello...
>> Adding /tools/mkfs.so...
>> Adding /etc/fstab...
>> Link /etc/mnttab to /proc/mounts ...
>> Adding /greeting.js...
>> Adding /libenviron.so...
>> Adding /libuutil.so...
>> Adding /bin/sleep.so...
>> Adding /proc...
>> Adding /bin/cd.so...
>> Adding /etc/hosts...
>> Adding /usr/lib...
>> Adding /dev...
>> Adding /usr/lib/libgcc_s.so.1...
>> ...
>> ```
>>
>> Please let me know if suppressing this log speeds up the process, I never
>> had time to play with this myself, but I'm very curious :)
>>
>>
>>
>> Best Regards,
>> Miha
>>
>>
>>
>>
>> Dne četrtek, 02. november 2017 21.16.37 UTC+1 je oseba Waldek Kozaczuk
>> napisala:
>>>
>>> I think this might be a well known and undestood issue by capstan team
>>> but I wanted to uderstand why it happens for my own sake.
>>>
>>> In my scenario I am usually able to upload 300 of files totaling 60MB in
>>> 10-12 seconds (Java app) using capstan which I believe employs same
>>> mechanism as OSv build script (over a socket to cpiod). On other hand when
>>> I upload 13,000 small JS files (node app) totalling around 100MB it takes
>>> at least 3 minutes (when I use VirtualBox to run OSv instance I am
>>> uploading to it takes over 10 minutes). Both capstan and ODv I am uploading
>>> to run on the same machine.
>>>
>>> Why is the upload of small files at least 10 times slower than with
>>> bigger files? Is it because ZFS is not most efficient handling small files?
>>> Is it possibly of how the upload is implemented on capstan side?
>>>
>>> Any ideas how to speed it up? Would somehow compressing all files in one
>>> archive and uploading to cpiod as one tarball and then decompressing help?
>>>
>>> Regards,
>>> Waldek
>>>
>>> --
> You received this message because you are subscribed to the Google Groups
> "OSv Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to osv-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osv-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ZFS implementation reasons and challenges in OSv

[Dor Laor]

On Thu, Oct 5, 2017 at 11:29 AM, Kaeyan Jones <kjone...@uic.edu> wrote:

> Hi Dor,
>
> I very much agree that ZFS is the best filesystem one could adopt, huge
> fan of it myself. Given the dependency on RAM for storage performance in
> ZFS are there any adverse side effects to deployments of OSv for bursty
> workloads, particularly I/O latency sensitive ones?
>

Our ZFS snapshot from FreeBSD can use some updates and isn't as performing
as XFS on some cases.


>
> Is OSv using the OpenZFS implementation illumos? I've been assuming it is
> since in the USENIX ATC 2014 paper ZFS's selection was from FreeBSD and
> FreeBSD borrows theirs from illumos.
>

At the time we needed there wasn't a separate repository and later we were
too busy but consuming openZFS directly is the best choice today.


>
> Was BRTFS considered? Is the GPL licensing a deal breaker?
>

BTRFS has its caveats and BGP is a no go for a unikernel that resides
within the same addr space as the app.


>
> Is hardware passing not necessary then? From my understanding of the
> illumos implementation of ZFS (in using FreeNAS), ZFS requires direct
> hardware control; virtualization requires hardware passing of disks and the
> use of RAID controllers requires JBoD. To do otherwise and not give ZFS
> direct hardware control of the disk is an invitation to data loss. Is this
> not similarly the case for ZFS in OSv?
>
> Given the performance, features and stability of ZFS coupled with OSv's
> improved network stack, is OSv particularly popular for usage in
> network/storage workloads?
>

It's a less common case for unikernels.


>
> Thank you,
> Kaeyan
>
>
> On Oct 5, 2017 11:26 AM, "Dor Laor" <d...@scylladb.com> wrote:
>
> Hi Kaeyan,
>
> ZFS was and still is the best filesystem with a BSD license we could adopt.
> There is no problem with hardware control that we know about. Moreover,
> hypervisors
> do virtualize the hardware so you can have similar features in a VM (like
> multiqueue and NVMe)
> and even direct assignment.
>
> Best,
> Dor
>
> On Thu, Oct 5, 2017 at 9:16 AM, Kaeyan Jones <kjone...@uic.edu> wrote:
>
>> Hello,
>>
>> What were the reasons and rationale behind using ZFS for the main file
>> system of OSv?
>>
>> As I understand ZFS, it isn't a file system that plays nicely with
>> virtualization and demands hardware control. Did this not prove a problem
>> for OSv? How extensive is the testing of the ZFS implementation?
>>
>> Thank you,
>> Kaeyan Jones
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "OSv Development" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to osv-dev+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osv-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ZFS implementation reasons and challenges in OSv

[Dor Laor]

Hi Kaeyan,

ZFS was and still is the best filesystem with a BSD license we could adopt.
There is no problem with hardware control that we know about. Moreover,
hypervisors
do virtualize the hardware so you can have similar features in a VM (like
multiqueue and NVMe)
and even direct assignment.

Best,
Dor

On Thu, Oct 5, 2017 at 9:16 AM, Kaeyan Jones  wrote:

> Hello,
>
> What were the reasons and rationale behind using ZFS for the main file
> system of OSv?
>
> As I understand ZFS, it isn't a file system that plays nicely with
> virtualization and demands hardware control. Did this not prove a problem
> for OSv? How extensive is the testing of the ZFS implementation?
>
> Thank you,
> Kaeyan Jones
>
> --
> You received this message because you are subscribed to the Google Groups
> "OSv Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to osv-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osv-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Example of using virtio network interfaces from application code

[Dor Laor]

We did hack memcache to get packets directly from the device. You can
search for this example, it might be good enough for you

On Apr 12, 2017 7:12 AM, "Nadav Har'El"  wrote:

>
> On Mon, Apr 10, 2017 at 1:05 AM, Rick Payne (Offshore) <
> ri...@rossfell.co.uk> wrote:
>
>> Hi,
>>
>> Is there a good example that uses the virtio network interfaces direct?
>> ie. an application that uses ‘assign-net’ and talks directly to the network
>> interface code in OSv?
>>
>> I’m looking for a sample I can learn from.
>>
>
> Unfortunately, we never documented the "assigned virtio" API.
>
> Basically, the "assigned virtio" idea was to allow OSv to set up the
> virtio-net device, and then give the application an API to control it
> directly.
> Before a virtio device can be assigned to the application, OSv needs to
> know not to use it itself. The boot-time option --assign-net  tells OSv
> *not* to use a virtio-net device given to it by the host (if any), and
> instead assign it to the application.
>
> You can see see include/osv/virtio-assign.hh for the full API.
> For example, the application can then use osv::assigned_virtio::get() to
> get access to this device, and properly set it up and use it. Then the
> application can use this API to access the rings, to kick, and to get
> notifications.
>
> The only place we ever used this API (and even that we haven't tested in a
> long time, so I hope it didn't rot too much...) was in Seastar. Check out
> commit f497299f446846767eda74a7265411b573b5a280 for how we used it in
> Seastar
>
> It would be nice to turn this feature into something more lively and used,
> and better documented.
>
> Nadav.
>
> --
> You received this message because you are subscribed to the Google Groups
> "OSv Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to osv-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osv-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Example of using virtio network interfaces from application code

[Dor Laor]

On Sun, Apr 9, 2017 at 3:05 PM, Rick Payne (Offshore) 
wrote:

> Hi,
>
> Is there a good example that uses the virtio network interfaces direct?
> ie. an application that uses ‘assign-net’ and talks directly to the network
> interface code in OSv?
>

Not that I know of. It was a cool idea but most of the OSv applications are
just standard, unmodified apps
in Linux. If one writes a special app for OSv it's possible.
In the seastar project we actually wrote a virtio backend to extract
packets from the kernel but it wasn't the
device itself.


>
> I’m looking for a sample I can learn from.
>
> Cheers,
> Rick
>
> --
> You received this message because you are subscribed to the Google Groups
> "OSv Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to osv-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osv-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [RFC] aarch64: basic Xen support

[Dor Laor]

On Fri, Jan 20, 2017 at 8:57 AM, Roman Shaposhnik 
wrote:

> Hi Sergiy!
>
> this is super cool -- I've been very interested in seeing resurrected

support for OSv on Xen/ARM
>

+1!


> for a different project I'm working on. Would love to take a look at your
> code.
>
> Speaking of which -- did you forget to attach a patch or a link to
> your GH repo? The
> only link I see is the one to R-Car board
>
> Thanks,
> Roman.
>
> On Fri, Jan 20, 2017 at 3:04 AM, 'Sergiy Kibrik' via OSv Development
>  wrote:
> > hi OSv developers,
> > Here let me present you with some little work to allow OSv kernel to be
> loaded
> > under Xen hypervisor on AARCH64 platform.
> >
> > This is basic stuff, which allows to initialise kernel and see log
> messages.
> > No SMP support yet, no heavy PV drivers yet and no application can be
> run.
> >
> > Verified on Renesas R-Car board [1] and on qemu-aarch64 (for not to
> break anything)
> >
> > [1] http://elinux.org/R-Car/Boards/Salvator-X
> >
> > Makefile | 5 -
> > arch/aarch64/arch-dtb.cc | 9 -
> > arch/aarch64/arch-dtb.hh | 7 +++
> > arch/aarch64/arch-mmu.hh | 2 +-
> > arch/aarch64/arch-setup.cc | 84 ++
> --
> > arch/aarch64/boot.S | 3 +++
> > arch/aarch64/early-console.cc | 22 --
> > arch/aarch64/early-console.hh | 24 ++--
> > arch/aarch64/hypercall.S | 30 ++
> > arch/aarch64/preboot.S | 17 +
> > arch/aarch64/xen.cc | 27 +++
> > arch/aarch64/xen.hh | 17 +
> > bsd/aarch64/machine/xen/hypercall.h | 73 ++
> +++
> > bsd/sys/xen/hypervisor.h | 4 ++--
> > bsd/sys/xen/interface/arch-aarch64.h | 52 ++
> ++
> > bsd/sys/xen/interface/xen.h | 2 ++
> > compiler/include/intrinsics.hh | 2 +-
> > drivers/xenconsole.cc | 36 
> > drivers/xenconsole.hh | 31 +++
> > 19 files changed, 403 insertions(+), 44 deletions(-)
> >
> > --
> > regards,
> > Sergiy
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "OSv Development" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to osv-dev+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "OSv Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to osv-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osv-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: OSv HTML5 terminal

[Dor Laor]

On Jan 12, 2017 4:47 AM, "Pekka Enberg"  wrote:

On Thu, Jan 12, 2017 at 2:44 PM, Waldek Kozaczuk 
wrote:
> I embarked on a project to create HTML5 app that could act as a simple
shell
> environment to OSv same way as cli module does using REST apis.

Looks really nice!



+1 way to go Waldek


- Pekka

--
You received this message because you are subscribed to the Google Groups
"OSv Development" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to osv-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osv-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PATCH] Added OpenJDK Zulu compact profile base images and example apps for each profile

[Dor Laor]

On Tue, Sep 13, 2016 at 9:15 PM, Waldemar Kozaczuk 
wrote:

> The three apps openjdk8-zulu-compact* provide base images for Java 8
> compact profiles. Each of the 3 apps uses
> the https://github.com/wkozaczuk/openjdk8_compact_profiles_builder tool
> to build Java 8 compact profile JRE based
> on regular OpenJDK 8 JDK, in this case Zulu OpenJDK 8 builds (
> https://www.azul.com/products/zulu/).
>
> The other 3 apps are simple Java Hello apps that demonstrate usages of
> each of the base compact profiles.
>

This is a really cool contribution. Nice!


>
> Signed-off-by: Waldemar Kozaczuk 
> ---
>  java-compact1-example/Hello.java|  5 +
>  java-compact1-example/Makefile  |  7 +++
>  java-compact1-example/module.py |  5 +
>  java-compact1-example/usr.manifest  |  1 +
>  java-compact2-example/Hello.java|  5 +
>  java-compact2-example/Makefile  |  7 +++
>  java-compact2-example/module.py |  5 +
>  java-compact2-example/usr.manifest  |  1 +
>  java-compact3-example/Hello.java|  5 +
>  java-compact3-example/Makefile  |  7 +++
>  java-compact3-example/module.py |  5 +
>  java-compact3-example/usr.manifest  |  1 +
>  openjdk8-zulu-compact-common/common.gmk | 37
> +
>  openjdk8-zulu-compact-common/latest.sh  |  3 +++
>  openjdk8-zulu-compact1/Makefile | 11 ++
>  openjdk8-zulu-compact1/latest.sh|  2 ++
>  openjdk8-zulu-compact1/module.py| 24 +
>  openjdk8-zulu-compact1/usr.manifest | 20 ++
>  openjdk8-zulu-compact2/Makefile | 11 ++
>  openjdk8-zulu-compact2/latest.sh|  2 ++
>  openjdk8-zulu-compact2/module.py| 24 +
>  openjdk8-zulu-compact2/usr.manifest | 20 ++
>  openjdk8-zulu-compact3/Makefile | 11 ++
>  openjdk8-zulu-compact3/latest.sh|  2 ++
>  openjdk8-zulu-compact3/module.py| 26 +++
>  openjdk8-zulu-compact3/usr.manifest | 20 ++
>  26 files changed, 267 insertions(+)
>  create mode 100644 java-compact1-example/Hello.java
>  create mode 100644 java-compact1-example/Makefile
>  create mode 100644 java-compact1-example/module.py
>  create mode 100644 java-compact1-example/usr.manifest
>  create mode 100644 java-compact2-example/Hello.java
>  create mode 100644 java-compact2-example/Makefile
>  create mode 100644 java-compact2-example/module.py
>  create mode 100644 java-compact2-example/usr.manifest
>  create mode 100644 java-compact3-example/Hello.java
>  create mode 100644 java-compact3-example/Makefile
>  create mode 100644 java-compact3-example/module.py
>  create mode 100644 java-compact3-example/usr.manifest
>  create mode 100644 openjdk8-zulu-compact-common/common.gmk
>  create mode 100755 openjdk8-zulu-compact-common/latest.sh
>  create mode 100644 openjdk8-zulu-compact1/Makefile
>  create mode 100755 openjdk8-zulu-compact1/latest.sh
>  create mode 100644 openjdk8-zulu-compact1/module.py
>  create mode 100644 openjdk8-zulu-compact1/usr.manifest
>  create mode 100644 openjdk8-zulu-compact2/Makefile
>  create mode 100755 openjdk8-zulu-compact2/latest.sh
>  create mode 100644 openjdk8-zulu-compact2/module.py
>  create mode 100644 openjdk8-zulu-compact2/usr.manifest
>  create mode 100644 openjdk8-zulu-compact3/Makefile
>  create mode 100755 openjdk8-zulu-compact3/latest.sh
>  create mode 100644 openjdk8-zulu-compact3/module.py
>  create mode 100644 openjdk8-zulu-compact3/usr.manifest
>
> diff --git a/java-compact1-example/Hello.java
> b/java-compact1-example/Hello.java
> new file mode 100644
> index 000..a605554
> --- /dev/null
> +++ b/java-compact1-example/Hello.java
> @@ -0,0 +1,5 @@
> +public class Hello {
> +public static void main(String[] args) {
> +System.out.println("Hello, World!");
> +}
> +}
> diff --git a/java-compact1-example/Makefile b/java-compact1-example/
> Makefile
> new file mode 100644
> index 000..8a385c9
> --- /dev/null
> +++ b/java-compact1-example/Makefile
> @@ -0,0 +1,7 @@
> +module: Hello.class
> +
> +%.class: %.java
> +   javac -target 7 -source 7 $^
> +
> +clean:
> +   rm -rf *.class
> diff --git a/java-compact1-example/module.py b/java-compact1-example/
> module.py
> new file mode 100644
> index 000..216cf35
> --- /dev/null
> +++ b/java-compact1-example/module.py
> @@ -0,0 +1,5 @@
> +from osv.modules import api
> +
> +api.require('openjdk8-zulu-compact1')
> +
> +default = api.run('/java.so -cp /java-example Hello')
> diff --git a/java-compact1-example/usr.manifest
> b/java-compact1-example/usr.manifest
> new file mode 100644
> index 000..f62abc7
> --- /dev/null
> +++ b/java-compact1-example/usr.manifest
> @@ -0,0 +1 @@
> +/java-example/Hello.class: ${MODULE_DIR}/Hello.class
> diff --git a/java-compact2-example/Hello.java
> 

Re: How to start reading OSV

[Dor Laor]

Hi,

You can read this paper:
https://www.usenix.org/system/files/conference/atc14/atc14-paper-kivity.pdf
and browse the code for functional areas.

Dor

On Fri, Jul 15, 2016 at 5:20 AM, 禹舟键  wrote:

> Hi everyone,
> I am new fish here. I have ever read some micro-kernels' codes, eg. seL4
> .Could you give me some tips about how to start reading osv's code?  Do you
> have any integrated manual references or technical documentations about
> osv?
>
> --
> You received this message because you are subscribed to the Google Groups
> "OSv Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to osv-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osv-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.