From: Eric Wong Date: 2013-08-20T22:25:14+00:00 Subject: [ruby-core:56763] Re: [ruby-trunk - Feature #8788][Open] use eventfd on newer Linux instead of pipe for timer thread KOSAKI Motohiro wrote: > 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. On Linux 3.10 on x86_64, 64-byte L1 cache line size file->private_data: sizeof(struct eventfd_ctx) == 48 bytes sizeof(struct pipe_inode_info) == 136 bytes So 176 bytes and 2 FDs saved for every Ruby process. Fwiw, I often have hundreds of (mostly idle) Ruby processes on my systems running random scripts/daemons. I doubt most users will notice the difference. But maybe it will make a tiny difference somewhere (fewer cache lines touched, smaller select() footprint). I don't have a machine to forkbomb with Ruby, but overall size of Ruby is probably the limiting factor anyways. > > 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. I suppose it depends on the user. I'm don't know of anybody using eventfd with Ruby right now (but I'll be updating some of my projects to do so). > >> (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. Thanks for looking. Sorry I cannot provide real-world measurement/use case. Ideally, we wouldn't even need a timer thread and we could just use ppoll/pselect. But that would be a very intrusive change (and maybe too incompatible with C extensions).