00:29 <krzk> gordan: Lower frequency, 4x times less L2 cache

00:29 <krzk> And they are marketed " the most power-efficient multi-core processor."...

00:30 <krzk> gordan: so if even marketing calls them "power-efficient" they must be slow :)

14:27 <sjoerd> javier__: Heh, if you turn on ARCH_EXYNOS4 in the kernel HZ gets fixed to 200

14:27 <sjoerd> that's surprsigin

14:36 <javier__> sjoerd: yeah, that's surprising indeed. I tracked down to commit 10606aadb046 ("ARM: EXYNOS4: Update Kconfig and Makefile for the new ARCH_EXYNOS4")

14:37 <javier__> so I don't know if that is a requirement of just happen to be legacy code from the time when a fixed HZ was choosen for platforms

14:42 <sjoerd> worth a try i guess to see what happens if you disable that

14:44 <javier__> sjoerd: yeah, since the 200 seems to be what the S3C2410 had as a default and new samsung platforms where just added as a || in the Kconfig

14:44 <javier__> sjoerd: take a look to commit f80658137fc8 [ARM] Move HZ definition into Kconfig

15:36 <gordan> javier__ I think I see what you were referring to yesterday WRT RTCs. In 4.3 max didn't work until I did systohc on the s3c, and max has been working ever since then. But s3c doesn't seem to ever contain a valid time after a reboot.

15:37 <gordan> On 4.1.12 s3c forgets time, but max never starts working, even after systohc on the s3c.

15:39 <javier__> gordan: yes, so it seems something broke max77802 rtc in 3.19..v4.1 then the regression was fixed in v4.1..v4.3 but the fix never made it to stable (i.e: 4.1.x)

15:39 <gordan> Indeed.

15:40 <gordan> I'd expect a backport into the 4.1.x soon, though, since that's a LT branch. :)

15:41 <gordan> Not tried audio to any extent yet, but other than that 4.3 works well for me so far.

15:41 <javier__> gordan: yes but the problem is that patches that are backported are the ones that are marked as applicable for stable and many times the dev posting the patches forget that

15:41 <javier__> so the commmit has to be identified now and post to stable again for inclusion

15:42 <gordan> Sure. Who's the maintainer of that driver? :)

15:44 <gordan> A little surprised that adding the 4 A7 cores to the mix only increases peak throughput by at most 30% (and I haven't achieved that big a boost even on make -j24).

15:44 <javier__> gordan: hehe yes, I've on my TODO list to test 4.1.12 as you asked and will bisect but unfortuantely I'm busy now with other stuff

15:45 <gordan> Sure, my mentioning it wasn't meant as nagging. Apologies if it came across that way.

15:47 <javier__> gordan: no worries, I wish my day had more hours :)

15:47 <javier__> I will be able to look at that next week

15:48 <javier__> gordan: about the A7 Cores, the problem is that the CFS scheduler does not know about the cores asymmetry so it can't take the best decisions when scheduling

15:48 <javier__> from the scheduler pov all the cores are the same

15:54 <javier__> gordan: s/the problem is/I think the problem is

15:55 <javier__> so until we get the EAS support in the kernel, I don't think that disabling the b.L switcher is a good idea

15:56 <sjoerd> b.L switcher just behaved nasty in a bunch of cases though

15:58 <gordan> Sure, but when you are over-scheduling by a factor of 3 from userspace, and there's enough files to compile available, it still gets close to saturating all the cores, even if some jobs take longer than others.

15:59 <gordan> The main thing is to schedule all the user-experienced stuff like the web browser only on the fast cores.

15:59 <gordan> But the problem then is that they won't migrate down to the A7s when idle, so it loses the whole of the power management advantages.

16:00 <gordan> My solution is, now that I have it u-bootable, to have the default kernel with the normal bL switcher, and kernel without it for big compile jobs.