linux-kernel - Re: [RFC PATCH] sched: find the latest idle cpu

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: <52D69AFA.1060308@linaro.org>
Date:	Wed, 15 Jan 2014 22:28:10 +0800
From:	Alex Shi <alex.shi@...aro.org>
To:	Michael wang <wangyun@...ux.vnet.ibm.com>, mingo@...hat.com,
	peterz@...radead.org, tglx@...utronix.de,
	daniel.lezcano@...aro.org, vincent.guittot@...aro.org,
	morten.rasmussen@....com
CC:	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	fengguang.wu@...el.com, linaro-kernel@...ts.linaro.org
Subject: Re: [RFC PATCH] sched: find the latest idle cpu

On 01/15/2014 04:05 PM, Michael wang wrote:
> On 01/15/2014 02:45 PM, Alex Shi wrote:
> [snip]
>>
>> yes, to save your scenario, we need to know the next timer for idle cpu,
>> but that is not enough, interrupt is totally unpredictable. So, I'd
>> rather bear the coarse method now.
>>>
>>> So what about just check 'ts->tick_stopped' and record one ticking idle
>>> cpu? the cost could be lower than time comparison, we could reduce the
>>> risk may be...(well, not so risky since the logical only works when
>>> system is relaxing with several cpu idle)
>>
>> first, nohz full also stop tick. second, tick_stopped can not reflect
>> the interrupt. when the idle cpu was interrupted, it's waken, then be a
>> good candidate for task running.
> 
> IMHO, if we have to do gamble here, we better choose the cheaper bet,
> unless we could prove this 'coarse method' have more higher chance for
> BINGO than just check 'tick_stopped'...

Tick stopped on a nohz full CPU, but the cpu still had a task running...
> 
> BTW, may be the logical should be in the select_idle_sibling()?

both of functions need to be considered.
> 
> Regards,
> Michael Wang
> 
>>
> 


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