Issue #10009 has been updated by Eric Wong.


 Good to know it works for you.  Keep in mind TIME_QUANTUM_USEC=1000 is
 very low and may cause problems on some systems, too.
 
 My gut feeling is 100ms (default) is too high, but 10ms is too low
 (based on kosaki's comment).  Maybe 20ms - 50ms is acceptable.  There is
 a wide variety of configuration we must work with (even just on Linux).
 
 Can you try 20-50ms?
 
 
 About GVL:
 Replacing GVL with fine-grained locks is possible (and ko1 tried it),
 but performance suffered for single-thread cases.
 It should be possible to do with lock-free techniques, but that is
 difficult to get right.

----------------------------------------
Bug #10009: IO operation is 10x slower in multi-thread environment
https://bugs.ruby-lang.org/issues/10009#change-47764

* Author: Alexandre Riveira
* Status: Open
* Priority: Urgent
* Assignee: 
* Category: 
* Target version: 
* ruby -v: ruby 2.1 x ruby 1.9.2 with taskset
* Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN
----------------------------------------
I created this issue #9832 but not have io operation.
In the script attached I simulate IO operation in multi-thread environment.
For ruby 1.9.2 apply `taskset -c -p 2 #{Process.pid}` for regulates threads behavior.
The second Thread is a io operation

My results:

1) ruby 2.1.2
first 43500194
second 95
third 42184385

2) ruby-2.0.0-p451
first 38418401
second 95
third 37444470

3) 1.9.3-p545
first 121260313
second 50
third 44275164

4) 1.9.2-p320
first 31189901
second 897 <============
third 31190598

Regards


Alexandre Riveira


---Files--------------------------------
teste_thread_schedule_2.rb (1.05 KB)
teste_thread_schedule.py (953 Bytes)
teste_thread_schedule.rb (955 Bytes)
test_thread_sched_pipe.rb (1.01 KB)


-- 
https://bugs.ruby-lang.org/