[CCing the regression list, as it should be in the loop for regressions: https://docs.kernel.org/admin-guide/reporting-regressions.html] [TLDR: I'm adding this report to the list of tracked Linux kernel regressions; the text you find below is based on a few templates paragraphs you might have encountered already in similar form. See link in footer if these mails annoy you.] On 08.06.23 13:14, Jan Kara wrote: > On Mon 24-10-22 05:28:41, Shakeel Butt wrote: >> Currently mm_struct maintains rss_stats which are updated on page fault >> and the unmapping codepaths. For page fault codepath the updates are >> cached per thread with the batch of TASK_RSS_EVENTS_THRESH which is 64. >> The reason for caching is performance for multithreaded applications >> otherwise the rss_stats updates may become hotspot for such >> applications. >> >> However this optimization comes with the cost of error margin in the rss >> stats. The rss_stats for applications with large number of threads can >> be very skewed. At worst the error margin is (nr_threads * 64) and we >> have a lot of applications with 100s of threads, so the error margin can >> be very high. Internally we had to reduce TASK_RSS_EVENTS_THRESH to 32. >> >> Recently we started seeing the unbounded errors for rss_stats for >> specific applications which use TCP rx0cp. It seems like >> vm_insert_pages() codepath does not sync rss_stats at all. >> >> This patch converts the rss_stats into percpu_counter to convert the >> error margin from (nr_threads * 64) to approximately (nr_cpus ^ 2). >> However this conversion enable us to get the accurate stats for >> situations where accuracy is more important than the cpu cost. Though >> this patch does not make such tradeoffs. >> >> Signed-off-by: Shakeel Butt <shakeelb@xxxxxxxxxx> > > Somewhat late to the game but our performance testing grid has noticed this > commit causes a performance regression on shell-heavy workloads. For > example running 'make test' in git sources on our test machine with 192 > CPUs takes about 4% longer, system time is increased by about 9%: Thanks for the report. I noticed this is nothing urgent. Nevertheless to be sure the issue doesn't fall through the cracks unnoticed, I'm adding it to regzbot, the Linux kernel regression tracking bot: #regzbot ^introduced f1a7941243c #regzbot title mm: performance regression on shell-heavy workloads #regzbot backburner: not urgent according to reporter #regzbot ignore-activity This isn't a regression? This issue or a fix for it are already discussed somewhere else? It was fixed already? You want to clarify when the regression started to happen? Or point out I got the title or something else totally wrong? Then just reply and tell me -- ideally while also telling regzbot about it, as explained by the page listed in the footer of this mail. Developers: When fixing the issue, remember to add 'Link:' tags pointing to the report (the parent of this mail). See page linked in footer for details. Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) -- Everything you wanna know about Linux kernel regression tracking: https://linux-regtracking.leemhuis.info/about/#tldr That page also explains what to do if mails like this annoy you.
