Sorry for the long post ...
Indeed, after hard fixing the GPU clock down to 400 MHz, I got the old graphics performance back. a bit better actually, due to overall performance tweaks/Linaro toolchain probably. Maybe the default setting for the kernel (as part of the rom) should be 400 MHz and just allow people to overclock when wanted. At least it deserves a big fat entry in the FAQ section of the OP
But my Antutu end-score is still only 25929, far from the 28K or 30K some people are seeing. I feel also the phone is more sluggish than when being on CM11 or even on the 1st Linaro version. It shouldn't be like that. This is supposed to be the fastest/most battery friendly kernel/rom. And I support it !
I see my Storage I/O result is still only 882, while I used to have 1229 before. Partly to blame for the lower total Antutu score I guess.
The other real difference now and then (storage realated) is the f2fs partitions. Is it possible things are not smooth there?
I've read here (
http://forum.xda-developers.com/showthread.php?t=2697069) that there is a much higher /cache usage with f2fs than with ext4 due to the increased usage of logs, inherent to the filesystem design. Thanks to the repartitionning I now ended up with only 10 MB, Of which 4 MB is used.
This was the (by coincidence probably) the amount the benchmark guy saw when doing the ext4-f2fs comparison when testing with ext4.
When he was testing with f2fs , his /cache usage went up to 114MB. I'm interested to see other people's numbers. Maybe a red herring, just an idea.
I also found this reference to (sub)optimal cache size:
http://forum.xda-developers.com/showthread.php?t=1097464
And this guy didn't think it was worth it, implementing f2fs on Oppo5/Nexus4 (v comparabel to our hardware)
http://www.oppoforums.com/threads/q-f2fs-filesystem.16378/#post-211150
But that was just one opinion, maybe other people have real provable experiences.
I also read that the performance of f2fs goes down dramatically when the filesystem is getting fuller because it creates enormous amounts of used 'holes' scattered over the disk, by nature. When in need of larger space than attribuable, instead of using the log based approach it sometimes just writes randomly to the open locations it knows about, depending on the gc process being smart enough or not.
Now I have 495MB free of the 4GB on the userdata partition. And recently I had to remove apps when wanting to install new ones, even if I had still 300 MB left? Maybe related? Here I found the info on the Cleaning process :
https://www.kernel.org/doc/Documentation/filesystems/f2fs.txt. Is this working fine in our implementation?
I also checked using AndroBench my storage performance numbers, if people can also have a look where the difference might be:
Sequential Read (65.88 MB/s) low but maybe as expected with our -known- weak storage subsystem
Sequential Write (1.79 MB/s) v v low
Random Read (8.61 MB/s, 2206.53 IOPS(4K) v v low
Random Write (0.56 MB/s, 143.69 IOPS(4k) v v low
And most important, anyone having any other ideas on to solve it ?
Thanks for all effort so far!
