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: <20140529135510.GG11074@laptop.programming.kicks-ass.net>
Date:	Thu, 29 May 2014 15:55:10 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Vincent Guittot <vincent.guittot@...aro.org>
Cc:	mingo@...nel.org, linux-kernel@...r.kernel.org,
	linux@....linux.org.uk, linux-arm-kernel@...ts.infradead.org,
	preeti@...ux.vnet.ibm.com, Morten.Rasmussen@....com, efault@....de,
	nicolas.pitre@...aro.org, linaro-kernel@...ts.linaro.org,
	daniel.lezcano@...aro.org
Subject: Re: [PATCH v2 11/11] sched: replace capacity by activity

On Fri, May 23, 2014 at 05:53:05PM +0200, Vincent Guittot wrote:
> The scheduler tries to compute how many tasks a group of CPUs can handle by
> assuming that a task's load is SCHED_LOAD_SCALE and a CPU capacity is
> SCHED_POWER_SCALE.
> We can now have a better idea of the utilization of a group fo CPUs thanks to
> group_actitvity and deduct how many capacity is still available.
> 
> Signed-off-by: Vincent Guittot <vincent.guittot@...aro.org>
> ---

Right, so as Preeti already mentioned, this wrecks SMT. It also seems to
loose the aggressive spread, where we want to run 1 task on each 'core'
before we start 'balancing'.

So I think we should be able to fix this by setting PREFER_SIBLING on
the SMT domain, that way we'll get single tasks running on each SMT
domain before filling them up until capacity.

Now, its been a while since I looked at PREFER_SIBLING, and I've not yet
looked at what your patch does to it, but it seems to me that that is
the first direction we should look for an answer to this.
--
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