linux-kernel - Re: [patch v5 09/15] sched: add power aware scheduling in fork/exec/wake

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:	Mon, 25 Feb 2013 11:30:44 +0100
From:	Mike Galbraith <efault@....de>
To:	Alex Shi <alex.shi@...el.com>
Cc:	Preeti U Murthy <preeti@...ux.vnet.ibm.com>,
	Peter Zijlstra <peterz@...radead.org>,
	torvalds@...ux-foundation.org, mingo@...hat.com,
	tglx@...utronix.de, akpm@...ux-foundation.org,
	arjan@...ux.intel.com, bp@...en8.de, pjt@...gle.com,
	namhyung@...nel.org, vincent.guittot@...aro.org,
	gregkh@...uxfoundation.org, viresh.kumar@...aro.org,
	linux-kernel@...r.kernel.org, morten.rasmussen@....com
Subject: Re: [patch v5 09/15] sched: add power aware scheduling in
 fork/exec/wake

On Mon, 2013-02-25 at 17:53 +0800, Alex Shi wrote: 
> On 02/25/2013 11:23 AM, Mike Galbraith wrote:
> > On Mon, 2013-02-25 at 10:23 +0800, Alex Shi wrote:
> > 
> >> One of problem is the how to decide the criteria of the burst? If we set
> >> 5 waking up/ms is burst, we will lose 4 waking up/ms.
> >> another problem is the burst detection cost, we need tracking a period
> >> history info of the waking up, better on whole group. but that give the
> >> extra cost in burst.
> >>
> >> solution candidates:
> >> https://lkml.org/lkml/2013/1/21/316
> >> After talk with MikeG, I remove the runnable load avg in performance
> >> load balance.
> > 
> > One thing you could try is to make criteria depend on avg_idle.  It will
> > slam to 2*migration_cost when a wakeup arrives after an ~extended idle.
> > You could perhaps extend it to cover new task wakeup as well, and use
> > that transition to invalidate history, switch to instantaneous until
> > fresh history can accumulate.
> 
> Sorry for can not get your points, would you like to goes to details?

If you've been idle for a bit, your history is stale.
> And still don't understand of the idle_stamp setting, idle_stamp was set
> in idle_balance(), if idle_balance doesn't pulled task, idle_stamp value
> kept. then even the cpu get tasks from another balancing, like periodic
> balance, fork/exec/wake balancing, the idle_stamp is still kept.

The thought is that you only care about the somewhat longish idles that
bursty loads exhibits.  The time when ttwu() detects that it should
trash idle history to kick idle_balance() back into action seems likely
to me to be the right time to trash load history, to accommodate bursty
loads in a dirt simple dirt cheap manner.  The idle balance throttle
methodology may not be perfect, but it works pretty well, and is dirt
cheap.

> So, when the cpu goes to next idle_balance(), it's highly possible to
> meet the avg_idle > migration_cost condition, and start try to pull
> tasks, nearly unconditionally.
> 
> Does the idle_balance was designed to this? or we still should reset
> idle_stamp whichever we pulled a task?

                if (pulled_task) {
                        this_rq->idle_stamp = 0;
                        break;
                }

-Mike

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