Back to bug 1880670
| Who | When | What | Removed | Added |
|---|---|---|---|---|
| Red Hat Bugzilla | 2020-09-18 23:00:45 UTC | Pool ID | sst_platform_tools_rhel_8 | |
| Brandon Clark | 2020-09-18 23:08:50 UTC | CC | alanm, amike, brclark, casantos, jwright, mbliss, mkolbas | |
| Florian Weimer | 2020-09-25 13:43:28 UTC | Comment 1 is private | 1 | 0 |
| Takayuki Nagata | 2020-10-02 08:00:54 UTC | CC | tnagata | |
| Florian Weimer | 2020-10-02 20:32:06 UTC | Flags | needinfo?(brclark) | |
| Florian Weimer | 2020-10-05 08:15:17 UTC | CC | sipoyare | |
| Florian Weimer | 2020-10-14 11:54:30 UTC | Keywords | Bugfix, Patch, Triaged | |
| Status | NEW | ASSIGNED | ||
| Doc Text | Cause: On x86-64, the glibc implementation of string functions overestimated the amount of last-level cache available to a thread. Consequence: Calling memcpy on large buffers would negatively impact overall cache performance of the system. Fix: The last-level cache size is no longer scaled with the number of potential hardware threads in the system. Result: The string functions bypass caches for large buffers, avoiding undue cache impact on the rest of the system. | |||
| Doc Type | If docs needed, set a value | Bug Fix | ||
| Valentina Mukhamedzhanova | 2020-10-14 15:38:23 UTC | CC | vmukhame | |
| Red Hat One Jira (issues.redhat.com) | 2020-10-14 23:33:10 UTC | Link ID | Red Hat Issue Tracker - Private RHELPLAN-54536 | |
| Martin Cermak | 2020-10-15 14:07:09 UTC | CC | mcermak | |
| Martin Cermak | 2020-10-16 08:20:56 UTC | QA Contact | qe-baseos-tools-bugs | skolosov |
| Florian Weimer | 2020-10-20 07:51:49 UTC | Assignee | glibc-bugzilla | fweimer |
| Florian Weimer | 2020-10-21 14:39:03 UTC | Status | ASSIGNED | MODIFIED |
| Fixed In Version | glibc-2.28-133.el8 | |||
| Sajan | 2020-10-22 05:37:32 UTC | CC | sajan.karumanchi | |
| Florian Weimer | 2020-10-30 15:32:14 UTC | Status | MODIFIED | ASSIGNED |
| Summary | memcpy calls are slower for AMD processors on RHEL 8 than RHEL 7 | glibc: memcpy calls are slower for AMD processors on RHEL 8 than RHEL 7 | ||
| Florian Weimer | 2020-11-02 14:57:02 UTC | Depends On | 1893197 | |
| Florian Weimer | 2020-11-06 15:50:05 UTC | Status | ASSIGNED | MODIFIED |
| Fixed In Version | glibc-2.28-133.el8 | glibc-2.28-137.el8 | ||
| errata-xmlrpc | 2020-11-13 18:24:31 UTC | Status | MODIFIED | ON_QA |
| Sergey Kolosov | 2020-11-16 12:07:30 UTC | Status | ON_QA | VERIFIED |
| Petr Kovar | 2020-11-24 14:56:56 UTC | Docs Contact | zzoubkov | |
| Kamil Dudka | 2021-01-04 13:13:53 UTC | CC | kdudka | |
| Zuzana Zoubkova | 2021-01-04 17:24:40 UTC | Flags | needinfo?(fweimer) | |
| RHEL Program Management Team | 2021-01-07 14:06:35 UTC | Blocks | 1913750 | |
| RHEL Program Management Team | 2021-01-07 14:06:40 UTC | Keywords | ZStream | |
| Florian Weimer | 2021-01-07 17:12:07 UTC | Doc Text | Cause: On x86-64, the glibc implementation of string functions overestimated the amount of last-level cache available to a thread. Consequence: Calling memcpy on large buffers would negatively impact overall cache performance of the system. Fix: The last-level cache size is no longer scaled with the number of potential hardware threads in the system. Result: The string functions bypass caches for large buffers, avoiding undue cache impact on the rest of the system. | Cause: On x86-64, the glibc implementation of string functions wrongly estimated the amount of last-level cache available to a thread. Consequence: Calling memcpy on large buffers could negatively impact overall cache performance of the system, or the memcpy call itself could be slow. Fix: The last-level cache size is no longer scaled with the number of reported hardware threads in the system. Result: The string functions bypass caches for large buffers (and only for large buffer), avoiding undue cache impact on the rest of the system. |
| Flags | needinfo?(fweimer) | |||
| Jay Shin | 2021-01-14 01:32:37 UTC | CC | jaeshin | |
| Link ID | Red Hat Knowledge Base (Solution) 5514711 | |||
| Zuzana Zoubkova | 2021-02-12 16:29:23 UTC | Doc Text | Cause: On x86-64, the glibc implementation of string functions wrongly estimated the amount of last-level cache available to a thread. Consequence: Calling memcpy on large buffers could negatively impact overall cache performance of the system, or the memcpy call itself could be slow. Fix: The last-level cache size is no longer scaled with the number of reported hardware threads in the system. Result: The string functions bypass caches for large buffers (and only for large buffer), avoiding undue cache impact on the rest of the system. | .The `glibc` string functions now avoid negative impact on system cache on AMD64 and Intel 64 processors Previously, the `glibc` implementation of string functions incorrectly estimated the amount of last-level cache available to a thread on the 64-bit AMD and Intel processors. As a consequence, calling the `memcpy` function on large buffers either negatively impacted the overall cache performance of the system or slowed down the `memcpy` system call. With this update, the last-level cache size is no longer scaled with the number of reported hardware threads in the system. As a result, the string functions now bypass caches for large buffers, avoiding negative impact on the rest of the system cache. |
| Christian Horn | 2021-02-17 00:30:56 UTC | CC | chorn | |
| Florian Weimer | 2021-02-17 06:00:20 UTC | Summary | glibc: memcpy calls are slower for AMD processors on RHEL 8 than RHEL 7 | glibc: memcpy calls are slower for x86_64 processors on RHEL 8 than on RHEL 7 |
| errata-xmlrpc | 2021-05-18 00:31:08 UTC | Status | VERIFIED | RELEASE_PENDING |
| errata-xmlrpc | 2021-05-18 14:36:39 UTC | Status | RELEASE_PENDING | CLOSED |
| Resolution | --- | ERRATA | ||
| Last Closed | 2021-05-18 14:36:39 UTC | |||
| Pavel Najman | 2021-09-17 12:24:26 UTC | Pool ID | sst_platform_tools_rhel_8 | sst_pt_pcp_rhel_8 |
| Pavel Najman | 2021-09-17 12:34:06 UTC | Pool ID | sst_pt_pcp_rhel_8 | sst_pt_gcc_glibc_rhel_8 |
| Mark O'Brien | 2023-07-18 14:30:35 UTC | Pool ID | sst_pt_glibc_rhel_8 | sst_pt_libraries_rhel_8 |
Back to bug 1880670