[ruby-core:56763] Re: [ruby-trunk - Feature #8788][Open] use eventfd on newer Linux instead of pipe for timer thread

KOSAKI Motohiro <[e-mail]> wrote:
> Hi
> 
> On Sat, Aug 17, 2013 at 3:37 PM, Eric Wong <[e-mail]> wrote:
> > SASADA Koichi <[e-mail]> 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).