-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Damian!
It is quite odd, but I can't see any informative system calls in the trace that you have attached. May I ask you to try running `strace` with a `-f` flag just to make sure that we are not missing anything valuable. Thank you, Fedor. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJTMqurAAoJEPsOEJWxeXmZCtUP/3snL8KwgWJb8P/4U0+JLDQo npG9b9t1ox6i0KFoJH0vec02VS5mpaD9jffP3reKC+2Y/RDWAtH8MM22+tuWk1t+ WYZQbnqQZ7x4V0UnrL0IhdQGlBSCTE/SAKaFZQfnXJr156Ik/oNJlwYyqb2qNR3y j5rfwBRSTPi0qYfmRmhnWCEJH5iP6vLh3b9Q1mPA2EXzKRNr/A+HiY1FLR3/M0Oy LicwtIg43EW+b/rejlGh796oLZF733pKAo+K4HRE1md3pkXuAgAcGYwcjrQfXzmC ZtkryN2CTSXrhmOs8Zr+Uf002rqXvWiM8gTGLcEj0eSEGM42ZIVXvJVdgYZYWpm8 qdd7MQIyER92mhRqUjxqrfgHmjTfVK5BI4mfpzPCb4/bga+Qm+RHw9dDUhA7OAG/ LLaaCFHDxl+KvFZmEzIqx/ICdcoQq1XVN3Dd9/lV1sCZ0Ier0Jyxd3cM0e6v3xCq uME1k8PHUhJrACd3XW0aTXrNIun4Q4/peFd6+v0q86RpAM7eHBdjrXVRsVu2QQWZ Ux6UV3GVQWd11CtU6Bh/IBVQpfQdURbMxoka5ZJgVzyKSciPMdgjnz3jIefNiRFi LNDbPcmlmAVrxByya7OLgHJKJex0PJ8n4ZINCV4xyL+hbYgVFagBDfl2PtNJ24ug 1oUG0c2F209XqrhGTUO8 =XP8c -----END PGP SIGNATURE----- On Tue, Mar 25, 2014 at 2:06 AM, Damián Lezama <[email protected]>wrote: > I'm attaching strace output. Looks like just a single call to futex is > responsible for most of the spinning. I'm not an expert here, I'm not sure > I'm reading this correctly. Let me know if you want me to send other traces. > > > On Monday, March 24, 2014 2:09:04 PM UTC-7, Fedor Indutny wrote: > >> My guess would be that it waits a lot in `epoll_wait()`... Anyway, it >> would be good to take a look at some source sample, or just to have a test >> case. >> >> >> On Tue, Mar 25, 2014 at 1:04 AM, Damián Lezama <[email protected]>wrote: >> >>> Let's see if this helps. It is from a test run that took less than 5 >>> seconds, where I downloaded 100 files *one at a time*. There should not be >>> much contention here, and it is very strange that only 9 calls to futex can >>> spin so much. Any ideas? >>> >>> % time seconds usecs/call calls errors syscall >>> ------ ----------- ----------- --------- --------- ---------------- >>> 99.94 4.150578 461175 9 1 futex >>> 0.01 0.000599 5 119 mmap >>> 0.01 0.000550 6 85 mprotect >>> 0.01 0.000354 9 40 read >>> 0.01 0.000247 6 41 open >>> 0.00 0.000190 5 42 42 access >>> 0.00 0.000140 3 41 fstat >>> 0.00 0.000125 3 42 close >>> 0.00 0.000065 22 3 clone >>> 0.00 0.000031 5 6 brk >>> 0.00 0.000019 5 4 munmap >>> 0.00 0.000014 5 3 clock_gettime >>> 0.00 0.000012 6 2 eventfd2 >>> 0.00 0.000012 6 2 pipe2 >>> 0.00 0.000007 2 4 write >>> 0.00 0.000007 4 2 rt_sigaction >>> 0.00 0.000005 5 1 epoll_create1 >>> 0.00 0.000004 4 1 rt_sigprocmask >>> 0.00 0.000004 4 1 execve >>> 0.00 0.000004 4 1 getrlimit >>> 0.00 0.000004 4 1 set_tid_address >>> 0.00 0.000003 3 1 arch_prctl >>> 0.00 0.000003 3 1 set_robust_list >>> ------ ----------- ----------- --------- --------- ---------------- >>> 100.00 4.152977 452 43 total >>> >>> >>> >>> On Monday, March 24, 2014 11:00:11 AM UTC-7, Damián Lezama wrote: >>> >>>> Let me see what I can do about collecting strace data or sharing code. >>>> I wonder if you had some profiling/metrics to know how to expect. >>>> I'm writing to the disk as fast as I can (in my setup network is not the >>>> bottleneck, the disk is), and I'm writing in quite small chunks (16k >>>> because of libcurl). >>>> >>>> On Friday, March 21, 2014 11:23:05 AM UTC-7, Fedor Indutny wrote: >>>>> >>>>> Hi! >>>>> >>>>> I'm afraid it is hard to say what's going on without taking a look at >>>>> actual implementation. Is it opensource? >>>>> >>>>> If not - could you please provide `strace` output of your program >>>>> execution? >>>>> >>>>> Cheers, >>>>> Fedor. >>>>> >>>>> On Fri, Mar 21, 2014 at 10:20 PM, Damián Lezama <[email protected]> >>>>> wrote: >>>>> > Hi, >>>>> > >>>>> > I have a prototype that downloads multiple files at the same time >>>>> with libuv >>>>> > and libcurl. On my tests with very high bandwidth, the main loop >>>>> thread gets >>>>> > close to 100% CPU usage, while every thread pool thread is at about >>>>> 20% or >>>>> > 30%. If I run my prototype using the time command, I get very high >>>>> system >>>>> > time. If I remove the file system operations and just download and >>>>> discard >>>>> > the data, the CPU usage is very low and libcurl and libuv do a great >>>>> job. >>>>> > What may be going on here? >>>>> > >>>>> > Thanks, >>>>> > Damian >>>>> > >>>>> > -- >>>>> > You received this message because you are subscribed to the Google >>>>> Groups >>>>> > "libuv" group. >>>>> > To unsubscribe from this group and stop receiving emails from it, >>>>> send an >>>>> > email to [email protected]. >>>>> > To post to this group, send email to [email protected]. >>>>> > Visit this group at http://groups.google.com/group/libuv. >>>>> > For more options, visit https://groups.google.com/d/optout. >>>>> >>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "libuv" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To post to this group, send email to [email protected]. >>> Visit this group at http://groups.google.com/group/libuv. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- > You received this message because you are subscribed to the Google Groups > "libuv" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/libuv. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "libuv" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/libuv. For more options, visit https://groups.google.com/d/optout.
