linux-kernel - Re: [PATCH] sched: select 'idle' cfs_rq per task-group to prevent tg-internal imbalance

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, 30 Jun 2014 16:47:19 +0800
From:	Michael wang <wangyun@...ux.vnet.ibm.com>
To:	Mike Galbraith <umgwanakikbuti@...il.com>
CC:	Peter Zijlstra <peterz@...radead.org>,
	Rik van Riel <riel@...hat.com>,
	Ingo Molnar <mingo@...nel.org>, Alex Shi <alex.shi@...aro.org>,
	Paul Turner <pjt@...gle.com>, Mel Gorman <mgorman@...e.de>,
	Daniel Lezcano <daniel.lezcano@...aro.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] sched: select 'idle' cfs_rq per task-group to prevent
 tg-internal imbalance

Hi, Mike :)

On 06/30/2014 04:06 PM, Mike Galbraith wrote:
> On Mon, 2014-06-30 at 15:36 +0800, Michael wang wrote: 
>> On 06/18/2014 12:50 PM, Michael wang wrote:
>>> By testing we found that after put benchmark (dbench) in to deep cpu-group,
>>> tasks (dbench routines) start to gathered on one CPU, which lead to that the
>>> benchmark could only get around 100% CPU whatever how big it's task-group's
>>> share is, here is the link of the way to reproduce the issue:
>>
>> Hi, Peter
>>
>> We thought that involved too much factors will make things too
>> complicated, we are trying to start over and get rid of the concepts of
>> 'deep-group' and 'GENTLE_FAIR_SLEEPERS' in the idea, wish this could
>> make things more easier...
> 
> While you're getting rid of the concept of 'GENTLE_FAIR_SLEEPERS', don't
> forget to also get rid of the concept of 'over-scheduling' :)

I'm new to this word... could you give more details on that?

> 
> That gentle thing isn't perfect (is the enemy of good), but preemption
> model being based upon sleep, while nice and simple, has the unfortunate
> weakness that as contention increases, so does the quantity of sleep in
> the system.  Would be nice to come up with an alternative preemption
> model as dirt simple as this one, but lacking the inherent weakness.

The preemtion based on vruntime sounds fair enough, but vruntime-bonus
for wakee do need few more thinking... although I don't want to count
the gentle-stuff in any more, but disable it do help dbench a lot...

Regards,
Michael Wang

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

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