From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 84045395B826; Wed, 29 Apr 2020 16:23:09 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 84045395B826 From: "adhemerval.zanella at linaro dot org" To: glibc-bugs@sourceware.org Subject: [Bug libc/25860] stress-ng tsearch regressed ~14% with upgrade glibc from 2.29 to 2.30 Date: Wed, 29 Apr 2020 16:23:09 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: libc X-Bugzilla-Version: 2.30 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: adhemerval.zanella at linaro dot org X-Bugzilla-Status: WAITING X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: security- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: glibc-bugs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Glibc-bugs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2020 16:23:09 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D25860 --- Comment #5 from Adhemerval Zanella --- Assuming you are evaluating with default phronix testsuite options (-t 30 --metrics-brief --cpu 0 --tsearch 0) it seems an issue with scheduling pres= sure in fact. On 2.29 running 3 times I see different results: stress-ng: info: [386425] dispatching hogs: 8 cpu, 8 tsearch stress-ng: info: [386425] successful run completed in 30.08s stress-ng: info: [386425] stressor bogo ops real time usr time sys time bogo ops/s bogo ops/s stress-ng: info: [386425] (secs) (secs) (s= ecs) (real time) (usr+sys time) stress-ng: info: [386425] cpu 30473 30.02 115.61=20= =20=20=20=20 0.01 1014.98 263.56 stress-ng: info: [386425] tsearch 1614 30.03 117.01=20= =20=20=20=20 0.00 53.75 13.79 stress-ng: info: [390680] dispatching hogs: 8 cpu, 8 tsearch stress-ng: info: [390680] successful run completed in 30.10s stress-ng: info: [390680] stressor bogo ops real time usr time sys time bogo ops/s bogo ops/s stress-ng: info: [390680] (secs) (secs) (s= ecs) (real time) (usr+sys time) stress-ng: info: [390680] cpu 31081 30.04 118.73=20= =20=20=20=20 0.00 1034.82 261.78 stress-ng: info: [390680] tsearch 1747 30.03 118.68=20= =20=20=20=20 0.10 58.18 14.71 stress-ng: info: [390726] dispatching hogs: 8 cpu, 8 tsearch stress-ng: info: [390726] successful run completed in 30.06s stress-ng: info: [390726] stressor bogo ops real time usr time sys time bogo ops/s bogo ops/s stress-ng: info: [390726] (secs) (secs) (s= ecs) (real time) (usr+sys time) stress-ng: info: [390726] cpu 31284 30.02 118.59=20= =20=20=20=20 0.01 1042.11 263.78 stress-ng: info: [390726] tsearch 1668 30.02 118.49=20= =20=20=20=20 0.08 55.55 14.07 And binding with --taskset 0,1,2,3,4,5,6,7, the resulting seems more predictable: stress-ng: info: [391052] dispatching hogs: 8 cpu, 8 tsearch=20 stress-ng: info: [391052] successful run completed in 30.07s=20 stress-ng: info: [391052] stressor bogo ops real time usr time sys time bogo ops/s bogo ops/s stress-ng: info: [391052] (secs) (secs) (s= ecs) (real time) (usr+sys time) stress-ng: info: [391052] cpu 31143 30.02 118.17=20= =20=20=20=20 0.03 1037.31 263.48 stress-ng: info: [391052] tsearch 1700 30.03 118.58=20= =20=20=20=20 0.05 56.62 14.33 stress-ng: info: [391102] dispatching hogs: 8 cpu, 8 tsearch=20 stress-ng: info: [391102] successful run completed in 30.09s=20 stress-ng: info: [391102] stressor bogo ops real time usr time sys time bogo ops/s bogo ops/s stress-ng: info: [391102] (secs) (secs) (s= ecs) (real time) (usr+sys time) stress-ng: info: [391102] cpu 30881 30.03 117.65=20= =20=20=20=20 0.06 1028.19 262.35 stress-ng: info: [391102] tsearch 1698 30.03 118.87=20= =20=20=20=20 0.07 56.55 14.28 And using the same options with biding on 2.30 shows no significant perform= ance difference: stress-ng: info: [391146] dispatching hogs: 8 cpu, 8 tsearch stress-ng: info: [391146] successful run completed in 30.09s stress-ng: info: [391146] stressor bogo ops real time usr time sys time bogo ops/s bogo ops/s stress-ng: info: [391146] (secs) (secs) (s= ecs) (real time) (usr+sys time) stress-ng: info: [391146] cpu 31133 30.04 118.06=20= =20=20=20=20 0.04 1036.39 263.62 stress-ng: info: [391146] tsearch 1735 30.05 119.09=20= =20=20=20=20 0.11 57.74 14.56 And profiling does not show any significant output difference: x86_64-linux-gnu-2.29$ perf report --stdio -d libc.so [...] # Overhead Command Symbol=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20 # ........ ............... ................................. # 10.88% stress-ng-tsear [.] __tfind 10.58% stress-ng-tsear [.] __tdelete 7.31% stress-ng-tsear [.] maybe_split_for_insert.isra.0 5.70% stress-ng-tsear [.] __tsearch x86_64-linux-gnu-2.30$ perf report --stdio -d libc.so [...] # Overhead Command Symbol # ........ ............... ................................. #=20 10.90% stress-ng-tsear [.] __tfind 10.52% stress-ng-tsear [.] __tdelete 7.38% stress-ng-tsear [.] maybe_split_for_insert.isra.0 5.81% stress-ng-tsear [.] __tsearch I don't think there is a regression here. --=20 You are receiving this mail because: You are on the CC list for the bug.=