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)) 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
|