linux-kernel - Re: [RFC PATCH 0/2] sched: simplify the select_task_rq

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: <50FFA695.6010407@linux.vnet.ibm.com>
Date:	Wed, 23 Jan 2013 17:00:05 +0800
From:	Michael Wang <wangyun@...ux.vnet.ibm.com>
To:	Mike Galbraith <bitbucket@...ine.de>
CC:	linux-kernel@...r.kernel.org, mingo@...hat.com,
	peterz@...radead.org, mingo@...nel.org, a.p.zijlstra@...llo.nl
Subject: Re: [RFC PATCH 0/2] sched: simplify the select_task_rq_fair()

On 01/23/2013 04:49 PM, Mike Galbraith wrote:
> On Wed, 2013-01-23 at 16:30 +0800, Michael Wang wrote: 
>> On 01/23/2013 04:20 PM, Mike Galbraith wrote:
>>> On Wed, 2013-01-23 at 15:10 +0800, Michael Wang wrote: 
>>>> On 01/23/2013 02:28 PM, Mike Galbraith wrote:
>>>
>>>>> Abbreviated test run:
>>>>> Tasks    jobs/min  jti  jobs/min/task      real       cpu
>>>>>   640   158044.01   81       246.9438     24.54    577.66   Wed Jan 23 07:14:33 2013
>>>>>  1280    50434.33   39        39.4018    153.80   5737.57   Wed Jan 23 07:17:07 2013
>>>>>  2560    47214.07   34        18.4430    328.58  12715.56   Wed Jan 23 07:22:36 2013
>>>>
>>>> So still not works... and not going to balance path while waking up will
>>>> fix it, looks like that's the only choice if no error on balance path
>>>> could be found...benchmark wins again, I'm feeling bad...
>>>>
>>>> I will conclude the info we collected and make a v3 later.
>>>
>>> FWIW, I hacked virgin to do full balance if an idle CPU was not found,
>>> leaving the preference to wake cache affine intact though, turned on
>>> WAKE_BALANCE in all domains, and it did not collapse.  In fact, the high
>>> load end, where the idle search will frequently be a waste of cycles,
>>> actually improved a bit.  Things that make ya go hmmm.
>>
>> Oh, does that means the old balance path is good while the new is really
>> broken, I mean, compared this with the previously results, could we say
>> that all the collapse was just caused by the change of balance path?
> 
> That's a good supposition.  I'll see if it holds.

I just notice that there is no sd support the WAKE flag at all according
to your debug info, isn't it?

Which means there is no way to do load balance since we can even not
found a suitable sd for wake up...totally confusing me now ;(

Regards,
Michael Wang

> 
> Next, I'm going to try ripping select_idle_sibling() to tiny shreds,
> twiddle the balance path a little to see if I can get rid of the bad
> stuff for tbench, maybe make some good stuff for pgbench and ilk, ilk
> _maybe_ including heavy duty remote network type loads.
> 
> There's gonna be some violent axe swinging here shortly.
> 
> -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/