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:	Thu, 26 Jul 2007 15:00:25 -0700
From:	"Li, Tong N" <tong.n.li@...el.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	linux-kernel@...r.kernel.org, Chris Snook <csnook@...hat.com>
Subject: Re: [RFC] scheduler: improve SMP fairness in CFS

On Thu, 2007-07-26 at 23:31 +0200, Ingo Molnar wrote:
> * Tong Li <tong.n.li@...el.com> wrote:
> 
> > > you need to measure it over longer periods of time. Its not worth 
> > > balancing for such a thing in any high-frequency manner. (we'd trash 
> > > the cache constantly migrating tasks back and forth.)
> > 
> > I have some data below, but before that, I'd like to say, at the same 
> > load balancing rate, my proposed approach would allow us to have 
> > fairness on the order of seconds. I'm less concerned about trashing 
> > the cache. The important thing is to have a knob that allow users to 
> > trade off fairness and performance based on their needs. [...]
> 
> such a knob already exists to a certain degree, but i havent tested its 
> full effects on SMP fairness yet. If you pull my scheduler tree:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched.git
> 
> and if you enable CONFIG_SCHED_DEBUG, then all the sched-domain 
> parameters become runtime tunable under /proc/sys/cpu*.
> 
> Could you try to increase the cross-CPU rebalancing frequency and see 
> how it impacts the precision of your measurement? Tune 'min_interval' 
> and 'max_interval' down to increase the frequency of rebalancing.
> 
> 	Ingo

Yes, I'll do it when I find time. If anyone is willing to do the
testing, please let me know and I can post my benchmark. On the other
hand, I don't think tuning the existing knobs will help solve the
problem. The root of the problem is that the current load balancing
doesn't take into account how much time each task has been running and
how much it's entitled. This is why I'm proposing a new approach for
solving it. The new approach, as I said, will be much more fair/accurate
than the current one even without tuning those balancing intervals
(i.e., it's able to provide good fairness even if balancing is less
frequent).

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ