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]

Message-ID: <1404115601.5132.156.camel@marge.simpson.net>
Date:	Mon, 30 Jun 2014 10:06:41 +0200
From:	Mike Galbraith <umgwanakikbuti@...il.com>
To:	Michael wang <wangyun@...ux.vnet.ibm.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

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' :)

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.

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