Yes, I'd kindly ask for a patch that introduces the `--verbose` for cpiod, whole Capstan would benefit from it. The problem when using --redirect option is that ALL the output will then be redirected, not only cpiod's - which is not always desired. We usually want to see at least some logs from application to determine if everything works as expected. Having --redirect employed, you can't see a thing. And if OSv crashes for some reason, you're then not able to access the log file via http server because the OSv is not running anymore...
So fixing the issue only for cpiod at the moment would be fantastic! Dne ponedeljek, 06. november 2017 03.59.35 UTC+1 je oseba Waldek Kozaczuk napisala: > > Nadav, > > Thanks for the explanation. > > Meanwhile I think it would be worth to modify cpiod to support new > '--verbose' option that would make it print files/directories/symlink > information only when passed in. Unless you think it a bad idea I will try > to provide a patch to address this. > > Also I noticed OSv supports '--redirect' option that allows redirection of > STDOUT and STDERR to some arbitrary file. This would also help with the > slowness issue. One more unrelated question about redirect option - would > it also print to that file in case of OSv crashing (registers, stack trace, > etc)? > > Waldek > > On Sunday, November 5, 2017 at 10:22:08 AM UTC-5, Nadav Har'El wrote: >> >> On Sat, Nov 4, 2017 at 5:14 AM, Waldek Kozaczuk <jwkoz...@gmail.com> >> 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? >>> >> >> Yes, it is very slow. As Dor explained, it needs to do a lot of work on >> every individual character. >> >> It is completely synchronous: for every character it needs to write to an >> IO register (incurring the usual hypervisor exit cost), but then, things >> deteriorate: Before we output the next character we need to loops and check >> when the hypervisor consumed the previous character. If this doesn't happen >> immediately and for some reason the guest and hypervisor are on the same >> CPU, we may need to wait until a context switch which can take ages. >> >> I don't know why VirtualBox is particularly slow in this. Maybe it >> answers the serial port write less immediately or maybe threads are pinned >> to CPUs differently. >> >> Maybe isa_serial_console::putchar() can be done differently to make it >> more virtualbox friendly, worth checking. >> >> Two things thing that are definitely worth checking are: >> >> 1. Currently we assume that the UART has a buffer of only *one* >> character. Could it be possible that VirtualBox and even QEMU actually >> support larger UART buffers, which can be used to significantly reduce the >> silly exits and busy loops? >> For example Linux's tty/serial/8250/8250_core.c suggests that 16550A may >> have a 16-byte output FIFO. Some sources I read suggest that qemu also has >> a 16-byte TX FIFO. >> >> 2. Currently we busy-wait until we can output another character. It might >> make sense to use TX interrupts instead, so that we can immediately let the >> host threads run (and handle the characters in the fifo). >> >> I'll create an issue with these ideas, in case someone wants to work on >> it. >> >> >> >>> And it is extra slow on some hypervisors/emulators like VirtualBox? Does >>> this have anything with this recent patch - >>> https://github.com/cloudius-systems/osv/commit/a543b9e6dd8776c43e070ec1b677f2fe1dcbb72e >>> ? >>> >> >> No, this patch was about cases where there was no serial port at all, and >> input would hang. I don't think it's related to your case. >> >> >> -- 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.
