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: <20141008005007.GA7017@intel.com>
Date:	Wed, 8 Oct 2014 08:50:07 +0800
From:	Yuyang Du <yuyang.du@...el.com>
To:	Morten Rasmussen <morten.rasmussen@....com>
Cc:	peterz@...radead.org, mingo@...hat.com, dietmar.eggemann@....com,
	pjt@...gle.com, bsegall@...gle.com, vincent.guittot@...aro.org,
	nicolas.pitre@...aro.org, mturquette@...aro.org, rjw@...ysocki.net,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/7] sched: Introduce scale-invariant load tracking

Hi Morten,

Sorry for late jumping in.

The problem seems to be self-evident. But for the implementation to be
equally attractive it needs to account for every freq change for every task,
or anything less than that makes it less attractive.

But this should be very hard. Intel Architecture has limitation to capture all
the freq changes in software and also the intel_pstate should have no
notification.

For every task, this makes the updating of the entire queue in load tracking
more needed, so once again, ping maintainers for the rewrite patches, :)

Thanks,
Yuyang

On Mon, Sep 22, 2014 at 05:24:01PM +0100, Morten Rasmussen wrote:
> From: Dietmar Eggemann <dietmar.eggemann@....com>
> 
> The per-entity load-tracking currently neither accounts for frequency
> changes due to frequency scaling (cpufreq) nor for micro-architectural
> differences between cpus (ARM big.LITTLE). Comparing tracked loads
> between different cpus might therefore be quite misleading.
> 
> This patch introduces a scale-invariance scaling factor to the
> load-tracking computation that can be used to compensate for compute
> capacity variations. The scaling factor is to be provided by the
> architecture through an arch specific function. It may be as simple as:
> 
> 	current_freq(cpu) * SCHED_CAPACITY_SCALE / max_freq(cpu)
> 
> If the architecture has more sophisticated ways of tracking compute
> capacity, it can do so in its implementation. By default, no scaling is
> applied.
> 
> The patch is loosely based on a patch by Chris Redpath
> <Chris.Redpath@....com>.
> 
> cc: Paul Turner <pjt@...gle.com>
> cc: Ben Segall <bsegall@...gle.com>
> 
> Signed-off-by: Dietmar Eggemann <dietmar.eggemann@....com>
> Signed-off-by: Morten Rasmussen <morten.rasmussen@....com>
--
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