yashsingh1/xdaforums huggingface dataset:
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] mat9v:
First point, agreed, 1017Mhz it is :)

I think 1382Mhz:80 is just fine, it works well with my philosophy of quickly taking care of tasks, with hispeed set for 1017 it will rarely go there for simple scrolling. Switching tasks will go to big cores anyway most likely.

Lets think about it rationally - how long does powering up fully this big core take (read HERE), what impact will it have on starting task if it is a new app loading? Will you be able to see a difference in load time if after whatever time is taken to power up the core it will take over the task? I dare you to prove it to me that you will be able to feel it. Not every design decision is worth upholding.

In my config, task starts on small core and migrates to big core, eventually to go back to small core once user input is required or task is finished (just as in your case, you are not suggesting it will stay there forever?), so it's only one step more. How much faster again will it start? Typical apps start time is on order of thousands of miliseconds so my core powering up sequence will completely disappear in it. How much battery will it constantly use just to sometimes start the task? Not worth it in my book.

CFQ and BFQ are both governors from times of rotational storage designed to hide latencies of such storage - I would love to have FIOPS here but when I can't have that I will choose "noop". Again I dare you to prove deadline is better then noop. Actually I like to have IO stats on for testing purposes, once I'm done I will turn them off. Big cache helps in random reads and that is more then 90% of all Android IO, I don't care that new app will install 0.5 seconds longer :) IO is busy decreases performance while giving me nothing - explain in details if you don't agree. I don't need to increase cpu frequency faster since it almost always jumps straight to 1305Mhz because of hispeed_frequency and hispeed_load. Agree with the last part, but with 3 times the tick I would set 78000 to get before 4th tick with testing - I haven't changed default values for sample time and hispeed_delay but as I understand they control how much longer to wait before going above hispeed, and so they control for how long we have to sustain load larger than "busy_up_thres" to actually increase frequency above hispeed. Generally it is to slow down ramping up speed beyond hispeed, right? I would increase it to save battery :)

Best regards RBAU :)
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] pehoko:
For me seems that auto brightness working strange and not properly. It is or dark or light, not always comfortable. Someone can do confirm?

And how to avoid "Privacy guard" questions, seems that didn't remember?
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] Zola III:
OK let's start with with power states:

http://www.embedded.com/design/powe...erstanding-MCU-sleep-modes-and-energy-savings

So it actually takes about 20+x more time than if the core is idling and waiting for interupt wile clock & caches are kept on minimum frequency. Ideal state from those that ARM support for all other cores in a cluster than first one would be when only L1 cache is idling on minimum frequency & rest of logic is in a sleep mode with power rail powerd off & it consumes fairly litle energy to be mentioned but I think we don't really know how to achieve that currently. Then again you must add cuple of hundreds of CPU cycles for migrating tasks from cluster to cluster if they start on a wrong one or for any migration at all.

Now let's see about big litle cores and migrations on various tasks:

https://www.google.ba/url?sa=t&sour...6jhm3cuNOlzrbYgjw&sig2=o7yuuWCIGgByiYKWbk8rYw

When you finish reading you will see how actually containing it all or most of it on litle cores actually isn't such a good idea neither performance wise nor much beneficial regarding power consumption. Ideal would be having one big core idling so that it can start processing emidiatly and there for start proces rather than migrate it & another one in the state where it can be easily waked up & employed on the same task sharing the workload from L2 cache also most processes are only capable of SMP on two core's. It would be also ideal to have only two small cores running as a minimum but to achieve that we will need additional configurable hot plug. So at the end it's one big +2 small cores with one additional big one that can easily & fast jump in as the ideal combo configuration regarding both performance and power efficiency.

Last but not least. Linux IO governor's how it whose:

http://www.phoronix.com/scan.php?page=article&item=linux_316_iosched&num=2

& a current mainline state as it is:

http://openbenchmarking.org/result/1610259-LO-LINUX49SC61

Keep in mind we are still on 3.10 modified Linux kernel and would be happy if achieved the 3.16 state presented hire, certainly very far from mainline Linux. Also let me remind you how deadline is actually almost real-time so wait times are shorter (leading to better responsiveness) then from others. It doesn't brake any records but it's still overlay the best one in all conditions summed up together. Nope will win in simple tasks as coping big files but it will also fall miserable when back seeks are involved (& that is rarely) and generally when things become complicated (which is more often) as for gaming.

I can't shorten this up & even this I presented seam so far is not really enough I unfortunately don't have time to get into this on more dubious & academic level so you can either search & read more and or try trusting me. Anyway choice is yours. Best regards.

Edit: seams you got a fun(boy) around hire following you. ??????
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] andjohn:
Hey All,

I noticed a regression from the latest, to the one before. Bluetooth devices don't autoconnect, from my headset to 2 different audio devices (usb powered bluetooth to aux adapters). I can tap on the name of the paired device and it will immediately connect, but it's like it doesn't notice that it's there. Also, I noticed that Gmail isn't staying in sync when the screen's off, so perhaps both are related to Doze?

This did work in the previous version, last in January.
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] Zola III:
Not related, first is probably a config related & second one is API implementation related. Their is still much work to be done on the ROM side from the LineageOS team & they are straightening it up slowly.

Hire is a recommendation for an unofficial app for anyone keen to follow how it progresses in more Android (& generally than Gareth) friendly manner:

https://play.google.com/store/apps/details?id=com.vasudevrb.cmchangelog

Edit: & apparently new official build is up or shortly coming up.
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] mat9v:
First thing, IO :) The test you linked is for Linux with normal SSD with full blown SATA controller. This is much different from our phones (kernel differences notwithstanding) and I stand by my opinion that for mostly read only environment we have here noop is better. If you want, take a few games and measure start time with different governors after cold boot. Academic discussion is all well and fun but let's stay on our phones :)

We don't even have the newer flash controllers that are present on SD820 so the comparison is even worse here. If you can find results for noop vs deadline on Android on similar hardware controller I may yet change my mind :)

On the big core issue you are kind of right from one side - it would be better for the task to start on big core, faster, but not power efficient. You say it takes lets say 25x transfer time from small to big core + transfer time, so at max 30x time and transfer time is 250 tics so we have 7500 tics (at CPU frequency of 1Ghz it means 1000.000.000 : 7500 = 133333 - so it means 1 by 133333 part of second to start the core and move the task) - all in all completely indistinguishable for the user. But battery savings are very real. If you did not have big cores the phone would still be perfectly smooth and would work correctly, big cores are here not to start tasks on them but to take care of big sustained loads like rendering webpage, playing games or car navigation. It's better to start task on small core because there is a chance that it will be sufficient to the task and the task will finish on it without even bothering big core. If we had only big cores then we could really play with frequencies (if you have time look at my config files for Galaxy Note and rationale behind them that I stated in my threads) but interactive governor is a POS that does not allow for any detailed configuration, you can't really program when to increase frequency, when to decrease frequency, at what queue length you should jump few frequencies straight up to the top. It's almost useless for my way of configuring cpus, that is why I hope so much for custom kernel.

Thank you for interesting discussion.

Best regards :)
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] laolang_cool:
hard to understand for my noob :o is there an easy way to let my phone has as long battery time as yours?
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] Zola III:
I can send you loads of benchmarks on Android regarding IO schedulers but they are all based on particular & suboptimal synthetic tests like Androbench & their are no real good ones up to date. It's possible to do a particular Discomark ones with cold start but should be a lot of work as you would have to do them app by app & kill that app process every time you switch scheduler & besides results wouldn't be much representive. Every other prick on every post regarding it actually just copy paste a description given on similar Linux discussions about schedulers. This one's are mostly used & they are really bad and old now, they are from Xperia Z2 with Androbench 4:

http://m.imgur.com/bCRBXZi?r

http://m.imgur.com/XUlhWl6?r

& they don't represent much if anything at all. So you see Linux ones that I did send you are still most representable and accurate ones all do even those you can take with a grain of salt. Bottom line is deadline doesn't have weak points regarding any workload while noop have several & this is not a specialised workload server so that you can pick & chose those that are best only for that tipe of work but best overall one as all workloads will happen including even database ones. Another point that most benchmark up to date actually disregard is how fast actual task is started & executed in a IO work queues & that is particularly important for user experience on Android and Discomark shines hire. Deadline is almost a real-time hire wile noop know to be relatively lazy. As the most of the IO tasks will still remain smal to medium on Android deadline will win hire even if he have a little smaller output than nope in particular case because simply it will start executing request sooner.

Looks like you really didn't read that pdf academic evaluation with benchmarks & power consumption so I don't really have anything to say to you about that nor we can continue discussion until you do regarding CPU's. Let me point out that CPU blocks count in only for average 15% of gates on the SoC so they aren't biggest potential power consumers on the other hand as a main general purpose execution part they do count in significantly as they are always used contrary to the other more specialised blocks that have their time off more often. Last but not least Interactive CPU governor is very configurable on many aspects from; particular frequency to particular loads (two different calculations) per given frequency & clock timer settings & regarding its primary design policy (that you can't change) can be adjusted very good.
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] Zola III:
Not that one that is a web page & those power states actually represent common ones that we usually call C1 to C4 that are the basic states represented on every architecture (x86, MIPS, ARM & cetera). If their represent significant differences based on usage & implementation on a best in class tiny microcontroller ARM core then guess what difference will become much more significant on size of the magnitude larger cores especially with lots of them. Any way only purpose of that web article whose to get to know you how those retention sleep basics states actually work.

You didn't read the pdf (second link) which is academic evaluation based on different workloads benchmarked & measured on a hexa big litle SoC (fairly similar to S650) the base hypothesis behind that science work is how will execution of tasks be conducted on a different core's, different numbers of employed active cores & different clusters what is the performance/power consumption impact.

Read that if the link doesn't work PM me to send you a nother one.

I always preferred Alucord then lulzactiveq but to be fair we can call them a same thing. They are also a hot plugs which interactive isn't its just a CPU governor in good old sense of that word. Now find private conversations we had 40-60 day's ago regarding Interactive governor configuration if you didn't delate them & read it again. No one does VVD's anymore... Interactive whose designed to scale really fast (& that's why it's considered best performance one) but if you know where & how to place the bricks to prevent him going out of acceptable uper frequency range without real need for that it becomes also power efficient friendly actually it becomes best power/performance option (the philosophy behind it actually goes with believes you suport). We do need a good enough configurable hot plug, that much is certain & me by that much can be pushed in a regular kernel. In the mean time Interactive & deadline represent mainline so they are no problem for something like that. If you wish to do some tests regarding IO schedulers please do Discomark ones for typical heavy apps like Facebook, Chrome, Google Maps & some essential ones would be much more eager to see those then large block & linear bunch of small file ones (also do a little gaming that includes sudden quick load of objects - racing or something like that). Deadline is my favourite for at least last 12 years. By the way Interactive governor present in our current kernel is a simplified one with less tunables (which is not necessarily a bad thing) all do I would like to see more complex one (as its more configurable that way).
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] AmokPL:
TBH at first I tried to follow up and understand it, now I am just scrolling :)
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] carnby24:
can someone tell me if the adopted storage function is working or not?
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] Makshow:
I didn't want to interrupt that nice talk, but I stumbled on an article on Snap 820 battery saving and an interesting post: here.

That's an opinion that CPU freq has more impact on battery consumption than voltage. So really, why don't save some extra mW?

Also, I installed an old Kernel Adiutor Mod for turning SELinux to permissive and found that this version of KA doesn't have the same core control settings as in new KA. There are settings for Min and Max Little CPUs online, and they are working! Yeap, LITTLE cluster hotplugging (see screenshot, CPU stats in upper right)! These settings can't be saved though and min/max big CPUs settings aren't working. And whole CPU settings tab isn't even loading...

By the way, as Geekbench 4 is saying, (on helium) we have single-core score of 1476 that is comparable to SD820 score of Samsung S7 (it's 1550) and multi-core score of 4710 that is much more than SD820 multi-core score of 3863. Why do we even need SD820? (oh, yeah, GPU is worse, OK).
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] seti007:
Thanks for a great rom. Fast and good battery life. Sorry if this question has been asked before. I did a search and could not find it. How do I disable screen wake up when I receive a notification. Looks like the screen always wakes up when I get up message like WhatsApp or text. I've tried headsoff but it disable the notifications on the lock screens completely. I still want to get the notifications but just want this phone to vibrate or make a sound and not wake the screen up. This is the first rom I'm having this issue with. Thanks

Edit: found a solution under ambient display. Turned it off there and now the screen does not wake up.
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] mat9v:
Heh, most of those high scores are made by me :) I experimented with interactive configuration to move most tasks to big cores, if at the start your phone is really cool, you can get even higher score :)

SD820 would score even higher but it is tuned in such a way as to prevent overheating that is a large problem for it's GPU part, so they are saving power and heat production by moving task execution to small cores.

I will take a look at this mod, it would be great to be able to limit small cores and leave only 1 small core on (at least for a testing run).

After a small kernel mod :) :

I wonder what will be the performance when only one small core is permanently active and big cores are turned on on demand.

Phone is perfectly smooth, no problem with that, I'm just thinking what benchmarks will say about it :)
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] adiif1:
First install firmware later rom?
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] mat9v:
No, first rom, then gapps (or not) and firmware last.
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] Klanac89:
Can somebody help me, please?

First time I'm really confused about flashing CM/LOS
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] troyinjapan:
I just updated last night from my Weekly Xiaomi.eu Helium ROM.

I followed the directions in the very first post in this thread.

1. Updated TWRP to 3.0.3-1 here.

2. After updating TWRP, I downloaded everything from the very first post here:

HELIUM: lineage-14.1-20170201-UNOFFICIAL-helium.zip

firmware-HELIUM_MDG-7.1.5.zip

Open GApps ARM64, 7.1, nano

and put them on my internal storage..

3. In TWRP, wiped and first selected the LinageOS rom (lineage-14.1-20170201-UNOFFICIAL-helium.zip) and added additional zips (firmware and GApps). Swiped right and rebooted.

4. In Developer options, enabled root.

Never used CM or LineageOS before. Hopefully you get it working.
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] astherion:
Does anybody use CDMA network? No data connection for me. I use cdma ruim card. Also no data connection in miui 7.1.19. In latest stable rom (6.12.22) all works fine, but it on android 6.0
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] seti007:
Hey guys, I installed the latest rom but did not install either of the two firmwares mentioned on the first page. Everything seems to be working perfectly at least after a couple of days of using it. Would I gain anything by flashing either one of those?

Thanks
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] Zola III:
Would actually stick to two litle ones as a minimum & one big cores as a minimum in active idle state, should be best performance/power combo not to push the little one to be to much jumpy all the time. Also if you want read the conclusion of that pdf (https://www.google.ba/url?sa=t&sour...6jhm3cuNOlzrbYgjw&sig2=o7yuuWCIGgByiYKWbk8rYw) & let me remind you all how SMP is supported on the Android platform for a very long time (from ICS), most of apps use SMP on two core's and this is become dominant (for updated apps) since late JB, luckily this day's we see more & more apps that use native ARMv8-a libs which is next performance step up (especially regarding SIMD operations).

The GPU on S820 is actually literally the A510 x2 (two clusters at A510 vs 4 on A530) & higher clocked but even with 14nm FinFET it throttles much more in real extended usage.

Best regards.
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] gotoanddie:
Is there a working Hydrogen to Helium ROM patch zip with all big cores activated, or are there instructions to do so manually?
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] i04055:
Why is that after using your profile, at least one of my big core always at 100% load?

It eat up my battery quiete fast, compare to default profile. How do i get back to default profile?
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] Zola III:
Easily, set the app you are using not to apply it after boot & restart the phone.
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] nijel8:
No, you will not...
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] mat9v:
You would have to tell me what you did - what changes you did, did you only mess with Kernel Adiutor or did you edit init.qcom.power.rc in kernel, or maybe did you flash my kernel that I have linked somewhere?

[MENTION=4232632]Zola III[/MENTION] - A510 has MP4 configuration and A530 has MP12 and higher frequency. Adreno 530 and Adreno 510
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] i04055:
I just use your setting for Kernel Adiutor...

I don't change the build.prop and init.qcom.power.rc.....
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] Zola III:
[MENTION=2473722]mat9v[/MENTION] wrong it's 4 clusters 256 ALU units (A530) vs two clusters 128 ALU units (A510).
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] mat9v:
Then just turn off "set at boot" in kernel adiutor.

Are you certain? Do you have links for that? Anandtech speculated (because there is no official statement from Qualcomm as far as they were aware) that it was MP4 and MP12 config based on some tests they did and benchmark scores that I linked (over 1:3 score difference, with imperfect scaling and frequency difference that would make sense).
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] Zola III:
Pretty much certain at least regarding the A530 that QC advertised much more so almost everyone (teach sites) quote that its a quad cluster. Bringed up the ALU caunt numbers from Wiki to back up 4 vs two clusters beside performance projection match that up (the additional difference is from bit bigger clock's & faster RAM). It certainly can't be MP12 vs MP4 I don't know where you dig that? The Anandteach who's good before... Such a shame & waist.
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] mat9v:
Ok, I bow to Wikipedia knowledge :) At least I was not much mistaken in 530 being 3 times as powerful as 510 :) Probably why they stated that MP4 and MP12 was probable :)
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] Zola III:
Not really 3x -it's 2.3~2.45x but in extended usage with throttling it comes to only 1.35~1.45.

I really don't know about complete multiple cluster GPU story, QC whose known by its single cluster design that scales 100% I don't think they had any reason to change that no matter what prees peple are talking how ever ALU count & performance there we can use as reliable.
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] mat9v:
Oh, I go by benchmark scores and GFlops numbers - resulting performance in games especially after extended gameplay is only another reason why Snapdragon 810/820/821/835, Kirin 955/960 are almost useless from gaming standpoint.

I much prefer 652 that lasts much longer with stable fps :) and on Vulkan it is very very fast.
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] Skalexs:
Guys, im not sure but, all this is about nijels ROM? 4 last pages.....
[Xiaomi Mi Max ROMs, Kernels, Recoveries, & Other D] Zola III:
It's more about in general tuning performance and power consumption with usual mainline governor's (both CPU & IO) regarding S652 SoC (& full applicable on S650). We got a little carried away (sometimes) so sorry about that. It's interesting to madder's & people's looking how to tune up the settings. After proper tests I hope we will make it beneficial to everyone (either if maintainers set them as defaults or tough Kernel Auditor pre made file). We did discuss hire as this is only Mi Max costume rom that can properly use the all CPU cores find on S652. ?

Best regards & sory for bothering.