[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 <[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.


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