On 19/09/16 05:08 AM, Carsten Haitzler (The Rasterman) wrote:
> On Mon, 19 Sep 2016 11:07:15 +0200 Stefan Schmidt <ste...@osg.samsung.com> 
> said:
>> Hello.
>> On 16/09/16 21:11, Derek Foreman wrote:
>>> derekf pushed a commit to branch master.
>>> http://git.enlightenment.org/core/efl.git/commit/?id=a17ac66f0a0b089dde0b2e550523b0d59ec97f52
>>> commit a17ac66f0a0b089dde0b2e550523b0d59ec97f52
>>> Author: Derek Foreman <der...@osg.samsung.com>
>>> Date:   Thu Sep 15 16:05:25 2016 -0500
>>>     render_thread: Attempt to set affinity to a random fast core
>>>     We've been pinning the render thread for every EFL process to core 0.
>>>     This is a bit silly in the first place, but some big.LITTLE arm systems,
>>>     such as exynos 5422, have the LITTLE cores first.
>>>     On those systems we put all the render threads on a slow core.
>>>     This attempts to fix that by using a random core from the pool of fast
>>>     cores.
>>>     If we can't determine which cores are fast (ie: we're not on a
>>>     linux kernel with cpufreq enabled) then we'll continue doing what we've
>>>     always done.
>> I had to revert this patch as it broke all efl builds for me. Locally 
>> and on Jenkins. Edje_cc segfaulted on the in tree edc files. Error 
>> message is in the revert commit message.
>>  From the description here this change would still be needed but in a 
>> non breaking way. :)
> how about simply removing the pinning (affinity) entirely?
I thought about that...  The render thread's still going to take a
performance hit if it bounces from processor to processor much (it's
probably pathologically bad for cache invalidation?)

Also, if it bounces around on the "LITTLE" cores on a big.LITTLE system
it'll have really bad performance characteristics...

There's a group working on improving the scheduler to better handle non
uniform multi-processor systems, so eventually we shouldn't need this
anymore, but I think for now it's generally a win.

enlightenment-devel mailing list

Reply via email to