[Bugs] [Bug 1467614] Gluster read/write performance improvements on NVMe backend

[bugzilla at redhat.com]

https://bugzilla.redhat.com/show_bug.cgi?id=1467614

Manoj Pillai <mpillai at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|needinfo?(mpillai at redhat.co |
                   |m)                          |



--- Comment #47 from Manoj Pillai <mpillai at redhat.com> ---
(In reply to Krutika Dhananjay from comment #46)

I am hedging my bets a bit with phrases like "not convinced" :). If you have a
strong feeling about one of these locks being the root cause, don't let me talk
you out of it :).

Looking at how mutrace calculates contention time (mutrace.c; functions
pthread_mutex_lock and mutex_lock). Consider an example where a critical
section with 1ms execution time is guarded by a mutex, and 10 concurrent
requests are active. Total execution time should be ~10ms. Contention time as
calculated by mutrace, IIUC, would be roughly 0+1+2+...+9=45ms. With 50
concurrently active requests, execution time would be ~50ms and contention time
would be 49*(49+1)/2 or 24.5 times the execution time. 

In comment #44, fio output for the run with 48 jobs shows increase in avg
latency of ~1ms compared to the run with 24 jobs. Total no. of requests is
IOPs*run-time i.e. 23K*66. If the increase in latency for the 48-job run is
coming solely due to lock contention, contention time reported could in theory
go up by as much as 23*66 seconds.

Those are the reasons why I talked about expecting big increases in reported
contention time if lock contention is indeed the culprit here.

But since you asked I looked at the mutrace runs again and saw some problems
there. Not sure we can take decisions confidently based on the output we are
getting. Let me talk about that in a separate comment.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=Vy0I4o7eXL&a=cc_unsubscribe