lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 10 Dec 2020 09:00:49 +0100 From: Vincent Guittot <vincent.guittot@...aro.org> To: Mel Gorman <mgorman@...hsingularity.net> Cc: Peter Ziljstra <peterz@...radead.org>, Ingo Molnar <mingo@...hat.com>, LKML <linux-kernel@...r.kernel.org>, Aubrey Li <aubrey.li@...ux.intel.com>, Barry Song <song.bao.hua@...ilicon.com>, Juri Lelli <juri.lelli@...hat.com>, Valentin Schneider <valentin.schneider@....com>, Linux-ARM <linux-arm-kernel@...ts.infradead.org> Subject: Re: [PATCH 0/4] Reduce scanning of runqueues in select_idle_sibling On Wed, 9 Dec 2020 at 15:37, Mel Gorman <mgorman@...hsingularity.net> wrote: > > On Tue, Dec 08, 2020 at 03:34:57PM +0000, Mel Gorman wrote: > > Changelog since v1 > > o Drop single-pass patch (vincent) > > o Scope variables used for SIS_AVG_CPU (dietmar) > > o Remove redundant assignment (dietmar > > > > This reduces the amount of runqueue scanning in select_idle_sibling in > > the worst case. > > > > Patch 1 removes SIS_AVG_CPU because it's unused. > > > > Patch 2 moves all SIS_PROP-related calculations under SIS_PROP > > > > Patch 3 improves the hit rate of p->recent_used_cpu to reduce the amount > > of scanning. It should be relatively uncontroversial > > > > Patch 4 returns an idle candidate if one is found while scanning for a > > free core. > > > > Any other objections to the series? Vincent marked 1, 3 and 4 as > reviewed. While patch 2 had some mild cosmetic concerns, I think the > version and how it treats SIS_PROP is fine as it is to keep it > functionally equivalent to !SIS_PROP and without adding too many > SIS_PROP checks. while testing your patchset and Aubrey one on top of tip, I'm facing some perf regression on my arm64 numa system on hackbench and reaim. The regression seems to comes from your patchset but i don't know which patch in particular yet hackbench -l 256000 -g 1 v5.10-rc7 + tip/sched/core 13,255(+/- 3.22%) with your patchset 15.368(+/- 2.74) -15.9% I'm also seeing perf regression on reaim but this one needs more investigation before confirming TBH, I was not expecting regressions. I'm running more test to find which patch is the culprit > > -- > Mel Gorman > SUSE Labs
Powered by blists - more mailing lists