From: KOSAKI Motohiro Date: 2013-08-20T15:33:01-04:00 Subject: [ruby-core:56761] Re: [ruby-trunk - Feature #8788][Open] use eventfd on newer Linux instead of pipe for timer thread Hi On Sat, Aug 17, 2013 at 3:37 PM, Eric Wong wrote: > SASADA Koichi wrote: >> (2013/08/16 10:47), normalperson (Eric Wong) wrote: >> > eventfd is a cheaper alternative to pipe for self-notification (signals) on Linux >> > >> > I will submit patches in the next few days/weeks unless there are objections >> > (or somebody else wants to do it sooner). I'd also like to cleanup some of the existing #ifdefs in that area while I'm at it. >> >> Can we see the performance comparison? >> If we can see the clear difference, it can be acceptable. > > It's not for speed (signal handling performance should not be a > bottleneck), but halve FD use in userspace and reduce memory use inside > the kernel. How much increase number of maximum ruby processes? Can you measure it? I bet the difference is very small. > AFAIK, writing to a empty pipe still allocates a 4K page, eventfd avoids > that allocation/deallocation. Since Ruby is CoW/fork-friendly, this > should allow running more Ruby processes on a system. > > I also thought my own code had an FD leak when timer_thread_pipe_low was > introduced. Maybe this will reduce confusion for users who lsof Ruby > processes, since there are more pipe users than eventfd users. Well, that's not a good reason. You said your patch decrease your confusion but increase a confusion of other eventfd users. >> (If we can't see any difference, it only increase the source code >> complexity). > > I've tried to minimize the impact of my patch and keep the eventfd/pipe > difference minimal. Anyway, I haven't seen any bugs in your patch. I would see a measurement result.