From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: poffice@blade.nagaokaut.ac.jp Delivered-To: poffice@blade.nagaokaut.ac.jp Received: from kankan.nagaokaut.ac.jp (smtp.nagaokaut.ac.jp [133.44.2.24]) by blade.nagaokaut.ac.jp (Postfix) with ESMTP id CCF941BA00BB for ; Mon, 8 May 2017 14:53:24 +0900 (JST) Received: from voscc.nagaokaut.ac.jp (voscc.nagaokaut.ac.jp [133.44.1.100]) by kankan.nagaokaut.ac.jp (Postfix) with ESMTP id C73FCB5D808 for ; Mon, 8 May 2017 15:36:54 +0900 (JST) Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by voscc.nagaokaut.ac.jp (Postfix) with ESMTP id 6A15118D1D82 for ; Mon, 8 May 2017 15:36:55 +0900 (JST) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id BC28812072E; Mon, 8 May 2017 15:36:53 +0900 (JST) X-Original-To: ruby-core@ruby-lang.org Delivered-To: ruby-core@ruby-lang.org Received: from dcvr.yhbt.net (dcvr.yhbt.net [64.71.152.64]) by neon.ruby-lang.org (Postfix) with ESMTPS id EDCCA12045C for ; Mon, 8 May 2017 15:36:36 +0900 (JST) Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id 052FB1FDEA; Mon, 8 May 2017 06:36:33 +0000 (UTC) Date: Mon, 8 May 2017 06:36:33 +0000 From: Eric Wong To: ruby-core@ruby-lang.org Message-ID: <20170508063633.GA6821@starla> References: <20170402011414.AEA9B64CEE@svn.ruby-lang.org> <8a2b82e3-dc07-1945-55f9-5a474e89130b@ruby-lang.org> <20170402023514.GB30476@dcvr> <76459664-9857-4244-7d43-79b24e737efc@atdot.net> <20170403044254.GA16328@starla> <20170508003315.GA3789@starla> <38090d10-c6a1-5097-66af-130275d773ea@atdot.net> <2b47c736-08d8-095b-0454-2dd0b1020b03@atdot.net> <20170508030120.GB24763@starla> <94ca8f9a-7001-12d3-323d-8c5751569c51@atdot.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <94ca8f9a-7001-12d3-323d-8c5751569c51@atdot.net> X-ML-Name: ruby-core X-Mail-Count: 81035 Subject: [ruby-core:81035] Re: [ruby-cvs:65407] normal:r58236 (trunk): thread.c: comments on M:N threading [ci skip] 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" SASADA Koichi wrote: > On 2017/05/08 12:01, Eric Wong wrote: > >>> . > >> `Fiber.scheduler.add_auto_fiber{ ... }` (naming is not fixed) (operation > >> for scheduler) is my first idea. > > Too verbose, I think. If I want to type more, I would not be > > using Ruby :) How about adding kwarg to Fiber.new? > > This design introduce new aspect: can we make schedulers per a thread? Maybe; if we can avoid GVL and introduce more parallelism. However, I think having one epoll/kqueue FD is better for a whole process; maybe one epoll/kqueue per-core (not per-thread) at maximum. I can easily imagine Ruby doing 100 native threads in one process (8 cores, 10-20 rotational disks, 2 SSD), but 20000-30000 fibers. Side note: First, I would like to make fibers smaller. Right now rb_fiber_t stores all of the rb_thread_t struct, but not all fields get used. I started to work on splitting out to a new struct rb_thread_context_t earlier: https://80x24.org/spew/20170508040753.24975-1-e@80x24.org/raw (incomplete, I will work on it some more tomorrow) The end goal is to avoid storing all of rb_thread_t inside rb_context_t/rb_fiber_t; and only store rb_thread_context_t. That should reduce memory overhead and maybe make switching faster. Also, I think we can use uint32_t (or even uint16_t * 4096) to store stack sizes. Using 64-bit size_t represent a stack size is excessive.