linux-kernel - Re: [PATCH] sched: Reduce contention in update_cfs_rq_blocked

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 04 Aug 2014 13:52:31 -0700
From:	bsegall@...gle.com
To:	Jason Low <jason.low2@...com>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...nel.org>, linux-kernel@...r.kernel.org,
	Waiman Long <Waiman.Long@...com>, Mel Gorman <mgorman@...e.de>,
	Mike Galbraith <umgwanakikbuti@...il.com>,
	Rik van Riel <riel@...hat.com>,
	Aswin Chandramouleeswaran <aswin@...com>,
	Chegu Vinod <chegu_vinod@...com>,
	Scott J Norton <scott.norton@...com>, pjt@...gle.com
Subject: Re: [PATCH] sched: Reduce contention in update_cfs_rq_blocked_load

Jason Low <jason.low2@...com> writes:

> When running workloads on 2+ socket systems, based on perf profiles, the
> update_cfs_rq_blocked_load function constantly shows up as taking up a
> noticeable % of run time. This is especially apparent on an 8 socket
> machine. For example, when running the AIM7 custom workload, we see:
>
>    4.18%        reaim  [kernel.kallsyms]        [k] update_cfs_rq_blocked_load
>
> Much of the contention is in __update_cfs_rq_tg_load_contrib when we
> update the tg load contribution stats.  However, it turns out that in many
> cases, they don't need to be updated and "tg_contrib" is 0.
>
> This patch adds a check in __update_cfs_rq_tg_load_contrib to skip updating
> tg load contribution stats when nothing needs to be updated. This reduces the
> cacheline contention that would be unnecessary. In the above case, with the
> patch, perf reports the total time spent in this function went down by more
> than a factor of 3x:
>
>    1.18%        reaim  [kernel.kallsyms]        [k] update_cfs_rq_blocked_load
>
> Signed-off-by: Jason Low <jason.low2@...com>
Reviewed-by: Ben Segall <bsegall@...gle.com>

That said, it might be better to remove force_update for this function,
or make it just reduce the minimum to /64 or something. If the test is
easy to run it would be good to see what it's like just removing the
force_update param for this function to see if it's worth worrying
about or if the zero case catches ~all the perf gain. Paul, your thoughts?

> ---
>  kernel/sched/fair.c |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index bfa3c86..8d4cc72 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -2377,6 +2377,9 @@ static inline void __update_cfs_rq_tg_load_contrib(struct cfs_rq *cfs_rq,
>  	tg_contrib = cfs_rq->runnable_load_avg + cfs_rq->blocked_load_avg;
>  	tg_contrib -= cfs_rq->tg_load_contrib;
>  
> +	if (!tg_contrib)
> +		return;
> +
>  	if (force_update || abs(tg_contrib) > cfs_rq->tg_load_contrib / 8) {
>  		atomic_long_add(tg_contrib, &tg->load_avg);
>  		cfs_rq->tg_load_contrib += tg_contrib;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/