On Thu, 9 Mar 2017 15:30:42 +0000 "Dorau, Lukasz" <lukasz.dorau@xxxxxxxxx> wrote: > On Thursday, March 9, 2017 4:21 PM Steven Rostedt wrote: > > On Thu, 9 Mar 2017 15:01:38 +0000 (UTC) > > Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxxxx> wrote: > > > > > > > Another more likely scenario is if a multithreaded process > > > has many threads blocked (e.g. on a futex), and one of the threads > > > exits cleanly or forks. I suspect the kernel will just tear down the > > > other threads without hitting syscall exit. > > > > Maybe, if this happens multiple times, it could cause those kinds of > > numbers. A fork was done zero times according to the numbers. Maybe > > exit should be measured too. > > > > I have run the test again with exit: > > Results (60 sec): > futex: p 2968 r 401 (86% did not return (2567)) > poll: p 13251 r 3957 (70% did not return (9294)) > epoll_wait: p 1485 r 556 (62% did not return (929)) > select: p 8063 r 8066 (OK) > fork: p 0 r 0 (OK) > vfork: p 4 r 4 (OK) > clone: p 6962 r 6962 (OK) > exit: p 3 r 0 (100% did not return (3)) I expected exit not to have a return, that's the property of exit. But it shows that the above poll and friends is not because of exit and fork. Can you change your script to use syscall tracepoints instead of retprobes? -- Steve > mmap: p 71740 r 71740 (OK) > open: p 43822 r 43825 (OK) > close: p 79805 r 79806 (OK) > write: p 31080 r 31078 (0% did not return (2)) > read: p 108456 r 108449 (0% did not return (7)) > > Lukasz -- To unsubscribe from this list: send the line "unsubscribe linux-trace-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|