From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on starla X-Spam-Level: X-Spam-Status: No, score=0.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_BL_SPAMCOP_NET,SPF_HELO_PASS, SPF_PASS autolearn=no autolearn_force=no version=3.4.6 Received: from nue.mailmanlists.eu (nue.mailmanlists.eu [94.130.110.93]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id D514E1F4C1 for ; Thu, 14 Nov 2024 17:24:11 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (1024-bit key; unprotected) header.d=ml.ruby-lang.org header.i=@ml.ruby-lang.org header.a=rsa-sha256 header.s=mail header.b=ICLgzaHe; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=ruby-lang.org header.i=@ruby-lang.org header.a=rsa-sha256 header.s=s1 header.b=qr8w7gNP; dkim-atps=neutral DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ml.ruby-lang.org; s=mail; t=1731605049; bh=1O28LEyikia35FhL3J7xIu0PT7CsOyCorF1GjKFl9Jo=; h=Date:References:To:Reply-To:Subject:List-Id:List-Archive: List-Help:List-Owner:List-Post:List-Subscribe:List-Unsubscribe: From:Cc:From; b=ICLgzaHeqYS9uWzsjfth+FHjRC7hsEBXTKPr7sw2OYVfeJnU2lOP9c8oa3F9qPdgb ew6EFP+p0x4E/EuWyaSpNfrfYBjZGA594l/tTBE4yNX4SIRjlDyxROyTeyxa9WvpAV Ao4Y+/3o3bld86lOK6tsM1WM0Ne/EcEl0uQYYbOU= Received: from nue.mailmanlists.eu (localhost [IPv6:::1]) by nue.mailmanlists.eu (Postfix) with ESMTP id 166C544B43 for ; Thu, 14 Nov 2024 17:24:09 +0000 (UTC) Authentication-Results: nue.mailmanlists.eu; dkim=pass (2048-bit key; unprotected) header.d=ruby-lang.org header.i=@ruby-lang.org header.a=rsa-sha256 header.s=s1 header.b=qr8w7gNP; dkim-atps=neutral Received: from s.wrqvtvvn.outbound-mail.sendgrid.net (s.wrqvtvvn.outbound-mail.sendgrid.net [149.72.120.130]) by nue.mailmanlists.eu (Postfix) with ESMTPS id 2BBFA44B43 for ; Thu, 14 Nov 2024 17:23:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ruby-lang.org; h=from:references:subject:mime-version:content-type: content-transfer-encoding:list-id:to:cc:content-type:from:subject:to; s=s1; bh=GXZ3X2HJFKcP5BLgsljy6OmisNhIeGKn3Zn3rjhZBYo=; b=qr8w7gNPKEmSBrWAv09KuZmAw13ZyeLkZszQ0DUqb8l92e4Uh/8M95o/CapD47J+obM8 ZFUj3JGOYRztlUzjh1UC5k+1XrlS9VPOAC/6qjkOWBd0pm6W+AU88r9LVe4GiVDI9TJ8dI 3SU/uQfs3qCVIq18c6fS+usaA3VsqHNZZieD4ya4JmPVlG0vZ152Lgky2xP+zaja62WwJ4 /rgezbnUIlthzbQAyFythUEUrvsxzko+iYSZEobGcZFh5jeFLEA22aX6va3zgki0A6EUg7 JXr5ACe6xDoOrLba6MtcWGLPLMjEAkjE2KjTItyTfZX58yVQ+cl+oGQ4mhuADoKQ== Received: by recvd-7cc7f7d978-762fg with SMTP id recvd-7cc7f7d978-762fg-1-6736322B-D 2024-11-14 17:23:55.155229728 +0000 UTC m=+5441258.300176801 Received: from herokuapp.com (unknown) by geopod-ismtpd-9 (SG) with ESMTP id zv4iKFYaTGelgiBJW9Z9ag for ; Thu, 14 Nov 2024 17:23:55.069 +0000 (UTC) Date: Thu, 14 Nov 2024 17:23:55 +0000 (UTC) Message-ID: References: Mime-Version: 1.0 X-Redmine-Project: ruby-master X-Redmine-Issue-Tracker: Feature X-Redmine-Issue-Id: 20861 X-Redmine-Issue-Author: tenderlovemaking X-Redmine-Issue-Priority: Normal X-Redmine-Sender: tenderlovemaking 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-Redmine-MailingListIntegration-Message-Ids: 96603 X-SG-EID: =?us-ascii?Q?u001=2ElWMe69GVkz6xHw8adpMU6eTKSGZqJ7+E1FrjckpA7cvWAPDyDX2cAv9Do?= =?us-ascii?Q?wZtGRg2vsYQLU1U4jx+ljWd9jTs=2FpZn02mllaZG?= =?us-ascii?Q?4g2CkB4nYTDkhZ4PqU4anSg6GO3QwR379egwi84?= =?us-ascii?Q?ZTczykACsRIjA8tckGyxB6=2F41JEOEbJffCALPyK?= =?us-ascii?Q?SPn9Kh1tNIUW=2F=2Fyls3RG5TeRevSwEFyh5UH36i2?= =?us-ascii?Q?d4McLiqBxd1MbwL5bI6AVAJybSKK1pBr7DwRA4F?= =?us-ascii?Q?Iw81BRfdZnqkqoFWlS9i1jdOFA=3D=3D?= To: ruby-core@ml.ruby-lang.org X-Entity-ID: u001.I8uzylDtAfgbeCOeLBYDww== Message-ID-Hash: KVMBTICTGORV7VBKYEAKE4CX563R66S2 X-Message-ID-Hash: KVMBTICTGORV7VBKYEAKE4CX563R66S2 X-MailFrom: bounces+313651-b711-ruby-core=ml.ruby-lang.org@em5188.ruby-lang.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.9 Precedence: list Reply-To: Ruby developers Subject: [ruby-core:119932] [Ruby master Feature#20861] Add an environment variable for tuning the default thread quantum List-Id: Ruby developers Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: From: "tenderlovemaking (Aaron Patterson) via ruby-core" Cc: "tenderlovemaking (Aaron Patterson)" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Issue #20861 has been updated by tenderlovemaking (Aaron Patterson). ko1 (Koichi Sasada) wrote in #note-11: > This example doesn't make sense for the real app because nobody repeat sleeping for the constant. > Do you have any example similar to the example? > > But the current 100ms is not based on strong opinion (it equals to Linux time quantum), so I'm okay to make it configurable (I didn't check the patch though). As @ivoanjo posted, it's usually some kind of IO mixed with CPU. For example using `Net::HTTP` and the response is slow, or even making database queries. The `sleep` example is just a simple way to demonstrate the impact of the quantum on IO calls. ---------------------------------------- Feature #20861: Add an environment variable for tuning the default thread quantum https://bugs.ruby-lang.org/issues/20861#change-110654 * Author: tenderlovemaking (Aaron Patterson) * Status: Open ---------------------------------------- The default thread quantum is currently [hard coded at 100ms](https://github.com/ruby/ruby/blob/c7708d22c33040a74ea7ac683bf7407d3759edfe/thread_pthread.c#L323). This can impact multithreaded systems that are trying to process Ruby level CPU bound work at the same time as IO work. I would like to add an environment variable `RUBY_THREAD_DEFAULT_QUANTUM_MS` that allows users to specify the default thread quantum (in milliseconds) via an environment variable. It defaults to our current default of 100ms. I've submitted the patch [here](https://github.com/ruby/ruby/pull/11981). Here is a Ruby program to demonstrate the problem: ```ruby def measure x = Process.clock_gettime(Process::CLOCK_MONOTONIC) yield Process.clock_gettime(Process::CLOCK_MONOTONIC) - x end def fib(n) if n < 2 n else fib(n-2) + fib(n-1) end end # find fib that takes ~500ms fib_i = 50.times.find { |i| measure { fib(i) } >= 0.05 } sleep_i = measure { fib(fib_i) } threads = [ Thread.new { 100.times { sleep(sleep_i) # sometimes stalled waiting for fib's quantum to finish } puts "done 1" }, Thread.new { 100.times { fib(fib_i) }; puts "done 2" }, ] # We expect the total time to be about 100 * sleep_i (~5 seconds) because # theoretically the sleep thread could be done nearly completely in parallel to # the fib thread. # # But because the `sleep` thread is iterating over the sleep call, it must wait # for the `fib` thread to complete its quantum, before it can start the next iteration. # # This means each sleep iteration could take up to `sleep_i + 100ms` # # We're calling that stalled time "waste" total = measure { threads.each(&:join) } waste = total - (sleep_i * 100) p TOTAL: total, WASTE: waste ``` The program has two threads. One thread is using CPU time by computing `fib` in a loop. The other thread is simulating IO time by calling `sleep` in a loop. When the `sleep` call completes, it can stall, waiting for the quantum in the fib thread to expire. That means that each iteration on sleep can actually take `sleep time + thread quantum`, or in this case ~600ms when we expected it to only take ~500ms. Ideally, the above program would take `500ms * 100` since all `sleep` calls should be able to execute in parallel with the `fib` calls. Of course this isn't true because the sleep thread must acquire the GVL before it can continue the next iteration, so there will always be _some_ overhead. This feature is for allowing people to tune that overhead. If we run this program with the default quantum the output looks like this: ``` $ ./miniruby -v fibtest.rb ruby 3.4.0dev (2024-11-01T14:49:50Z quantum-computing c7708d22c3) +PRISM [arm64-darwin24] done 2 done 1 {TOTAL: 12.672821999993175, WASTE: 4.960721996147186} ``` The output shows that our program spent about 5 seconds stalled, waiting to acquire the GVL. With this patch we can lower the default quantum, and the output is like this: ``` $ RUBY_THREAD_DEFAULT_QUANTUM_MS=10 ./miniruby -v fibtest.rb ruby 3.4.0dev (2024-11-01T22:06:35Z quantum-computing 087500643d) +PRISM [arm64-darwin24] done 2 done 1 {TOTAL: 8.898526000091806, WASTE: 1.4168260043952614} ``` Specifying the ENV to change the quantum to 10ms lowered our waste in the program to ~1.4 seconds. It's common for web applications to do mixed CPU and IO bound tasks in threads (see the Puma webserver), so it would be great if there was a way to customize the thread quantum depending on your application's workload. -- https://bugs.ruby-lang.org/ ______________________________________________ ruby-core mailing list -- ruby-core@ml.ruby-lang.org To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org ruby-core info -- https://ml.ruby-lang.org/mailman3/lists/ruby-core.ml.ruby-lang.org/