linux-kernel - Re: Epic regression in throughput since v2.6.23

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:	Sun, 13 Sep 2009 21:17:52 +0200
From:	Mike Galbraith <efault@....de>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Serge Belyshev <belyshev@...ni.sinp.msu.ru>,
	Con Kolivas <kernel@...ivas.org>, linux-kernel@...r.kernel.org,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: Epic regression in throughput since v2.6.23

On Sun, 2009-09-13 at 17:47 +0200, Ingo Molnar wrote:
> * Serge Belyshev <belyshev@...ni.sinp.msu.ru> wrote:
> 
> > Note that the disabling NEW_FAIR_SLEEPERS doesn't fix 3% 
> > regression from v2.6.23, but instead makes "make -j4" runtime 
> > another 2% worse (27.05 -> 27.72).
> 
> ok - thanks for the numbers, will have a look.

Seems NEXT_BUDDY is hurting the -j4 build.

LAST_BUDDY helps, which makes some sense.. if a task has heated up
cache, and is wakeup preempted by a fast mover (kthread, make..), it can
get the CPU back with still toasty data.  Hm.  If NEXT_BUDDY is on, that
benefit would likely be frequently destroyed too, because NEXT_BUDDY is
preferred over LAST_BUDDY.

Anyway, I'm thinking of tracking forks/sec as a means of detecting the
fork/exec load.  Or, maybe just enable it when there's > 1 buddy pair
running.. or something.  After all, NEXT_BUDDY is about scalability, and
make -j4 on a quad surely doesn't need any scalability help :)

 Performance counter stats for 'make -j4 vmlinux':

stock
  111.625198810  seconds time elapsed  avg 112.120  1.00
  112.209501685  seconds time elapsed
  112.528258240  seconds time elapsed

NO_NEXT_BUDDY NO_LAST_BUDDY
  109.405064078  seconds time elapsed  avg 109.351  .975
  108.708076118  seconds time elapsed
  109.942346026  seconds time elapsed

NO_NEXT_BUDDY
  108.005756718  seconds time elapsed  avg 108.064  .963
  107.689862679  seconds time elapsed
  108.497117555  seconds time elapsed

NO_LAST_BUDDY
  110.208717063  seconds time elapsed  avg 110.120  .982
  110.362412902  seconds time elapsed
  109.791359601  seconds time elapsed


diff --git a/kernel/sched_fair.c b/kernel/sched_fair.c
index aa7f841..7cfea64 100644
--- a/kernel/sched_fair.c
+++ b/kernel/sched_fair.c
@@ -1501,7 +1501,8 @@ static void check_preempt_wakeup(struct rq *rq, struct task_struct *p, int sync)
 	 */
 	if (sched_feat(LAST_BUDDY) && likely(se->on_rq && curr != rq->idle))
 		set_last_buddy(se);
-	set_next_buddy(pse);
+	if (sched_feat(NEXT_BUDDY))
+		set_next_buddy(pse);
 
 	/*
 	 * We can come here with TIF_NEED_RESCHED already set from new task
diff --git a/kernel/sched_features.h b/kernel/sched_features.h
index e2dc63a..6e7070b 100644
--- a/kernel/sched_features.h
+++ b/kernel/sched_features.h
@@ -13,5 +13,6 @@ SCHED_FEAT(LB_BIAS, 1)
 SCHED_FEAT(LB_WAKEUP_UPDATE, 1)
 SCHED_FEAT(ASYM_EFF_LOAD, 1)
 SCHED_FEAT(WAKEUP_OVERLAP, 0)
+SCHED_FEAT(NEXT_BUDDY, 1)
 SCHED_FEAT(LAST_BUDDY, 1)
 SCHED_FEAT(OWNER_SPIN, 1)


--
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/