From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-2.7 required=3.0 tests=AWL,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY shortcircuit=no autolearn=no autolearn_force=no version=3.4.2 Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by dcvr.yhbt.net (Postfix) with ESMTP id 7B6541F66E for ; Mon, 17 Aug 2020 12:00:35 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 120261209CC; Mon, 17 Aug 2020 21:00:03 +0900 (JST) Received: from xtrwkhkc.outbound-mail.sendgrid.net (xtrwkhkc.outbound-mail.sendgrid.net [167.89.16.28]) by neon.ruby-lang.org (Postfix) with ESMTPS id 9E4261209CA for ; Mon, 17 Aug 2020 21:00:00 +0900 (JST) Received: by filterdrecv-p3iad2-canary-d884f9c76-74jbr with SMTP id filterdrecv-p3iad2-canary-d884f9c76-74jbr-18-5F3A715A-162 2020-08-17 12:00:26.545617037 +0000 UTC m=+329462.181115594 Received: from herokuapp.com (unknown) by ismtpd0092p1iad2.sendgrid.net (SG) with ESMTP id KvtBAMYGRfas6Ft2vkUG4g for ; Mon, 17 Aug 2020 12:00:26.511 +0000 (UTC) Date: Mon, 17 Aug 2020 12:00:26 +0000 (UTC) From: dsh0416@gmail.com Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 75444 X-Redmine-Project: ruby-master X-Redmine-Issue-Tracker: Feature X-Redmine-Issue-Id: 17059 X-Redmine-Issue-Author: dsh0416 X-Redmine-Sender: dsh0416 X-Mailer: Redmine X-Redmine-Host: bugs.ruby-lang.org X-Redmine-Site: Ruby Issue Tracking System X-Auto-Response-Suppress: All Auto-Submitted: auto-generated X-SG-EID: =?us-ascii?Q?JfUq2S2D3Hy6+ijZravGPs29zhqXCTJcgd4jfmDsi8ojRW971D8Ja39k=2F3sR9S?= =?us-ascii?Q?4TU+zuW3iL1GQVzN6oXFBxr9ITBAkYgtW96tfRh?= =?us-ascii?Q?AigzLIextCKP49sGnrxZ+YnNY1pq0OHYf2342k+?= =?us-ascii?Q?A4rhBxnombXLFZosI4qwSB4h6ahplVjNXSndL1h?= =?us-ascii?Q?1BERbYP9C0cMgnDMylvWTch663uuwoimMtH+ohV?= =?us-ascii?Q?x2wbvYF1a7ch9IkNg=3D?= To: ruby-core@ruby-lang.org X-ML-Name: ruby-core X-Mail-Count: 99616 Subject: [ruby-core:99616] [Ruby master Feature#17059] epoll as the backend of IO.select on Linux X-BeenThere: ruby-core@ruby-lang.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Ruby developers List-Id: Ruby developers List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" Issue #17059 has been updated by dsh0416 (Delton Ding). The benchmark looks good. I've tested with similar code, and it's 46x slower on my machine. It looks like `epoll` is highly depended on the time that `epoll_ctl` engaged. Since the scheduler now have other registration control including `rb_io_wait_readable` and `rb_io_wait_writable` are introduced in the current `Scheduler`. I would try to use these methods to deal with the registration then, and replace the `IO.select` in the `Scheduler#run` for performance. Is this a proper way to implement then? ---------------------------------------- Feature #17059: epoll as the backend of IO.select on Linux https://bugs.ruby-lang.org/issues/17059#change-87095 * Author: dsh0416 (Delton Ding) * Status: Open * Priority: Normal ---------------------------------------- Current Ruby's `IO.select` method calls POSIX `select` API directly. With the new non-blocking scheduler, this may be the bottleneck of the I/O scheduling. For keeping the backward compatibilty of the current `IO.select` methods, a proposal may be to create a "duck" `select` which uses the `epoll_wait` as the backend. One tricky part is that the `fd_set` described in POSIX is write-only, which means it is impossible to iterate for generating the `epoll_event` argument for `epoll_wait`. But similar to the large-size select situation, we could define our own `rb_fdset_t` struct in this case, and implement the following APIs. ``` void rb_fd_init(rb_fdset_t *); void rb_fd_term(rb_fdset_t *); void rb_fd_zero(rb_fdset_t *); void rb_fd_set(int, rb_fdset_t *); void rb_fd_clr(int, rb_fdset_t *); int rb_fd_isset(int, const rb_fdset_t *); void rb_fd_copy(rb_fdset_t *, const fd_set *, int); void rb_fd_dup(rb_fdset_t *dst, const rb_fdset_t *src); int rb_fd_select(int, rb_fdset_t *, rb_fdset_t *, rb_fdset_t *, struct timeval *); ``` TODO: 1. Implement the fd_set with dynamic allocated fds. 2. Implement the epoll with select API. 3. Edit io.c to use the customized fd_set struct. I'm trying to work on a branch for this. Any suggestions for this? ---Files-------------------------------- epoll.h (3.62 KB) epoll.h (6.44 KB) -- https://bugs.ruby-lang.org/