linux-kernel - Re: [RFC] scheduler: improve SMP fairness in CFS

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]

Message-Id: <1185225015.3593.15.camel@tongli.jf.intel.com>
Date:	Mon, 23 Jul 2007 14:10:15 -0700
From:	"Li, Tong N" <tong.n.li@...el.com>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	mingo@...e.hu, linux-kernel@...r.kernel.org
Subject: Re: [RFC] scheduler: improve SMP fairness in CFS

I benchmarked an early version of this code (against 2.6.21) with
SPECjbb, SPEComp, kernbench, etc. on an 8-processor system, and didn't
see any slowdown compared to the stock scheduler. I'll generate the data
again with this version of the code. On the other hand, if locking does
become a problem for certain systems/workloads, increasing
sysctl_base_round_slice can reduce the locking frequency and alleviate
the problem, at the cost of being relatively less fair across the CPUs. 

  tong

On Mon, 2007-07-23 at 22:00 +0200, Andi Kleen wrote:
> Tong Li <tong.n.li@...el.com> writes:
> > +
> > +        read_lock_irqsave(&dwrr_highest_lock, flags);
> 
> That lock looks like it would bounce between CPUs like crazy.
> Did you try any benchmarks on a larger system? 
> 
> -Andi
-
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/