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.
