You've took cache size for heap size. That's different things. hunderteins was referring for catalog with built dalvik cache (/data/dalvik-cache)
Oops my bad..... i have applied the changes...so far not much difference lets see...
You've took cache size for heap size. That's different things. hunderteins was referring for catalog with built dalvik cache (/data/dalvik-cache)
dalvik.vm.dexopt-flags=v=n,o=a,u=y,m=y (testing now with register optimization)
@Hunderteins
These settings make the DS5 works faster but after applying these settings some applications don't able to see superuser and can't get root permissions (like Lucky Patcher,Titanium Backup...)
@Hunderteins
These settings make the DS5 works faster but after applying these settings some applications don't able to see superuser and can't get root permissions (like Lucky Patcher,Titanium Backup...)
You see, in previous kernel builds I made an error in stepping table values, so 1267 was actually 1344, and 998 was 1075.
Now I fixed it.
Sorry
#CPU
echo "conservative" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo 70 > /sys/devices/system/cpu/cpu0/cpufreq/conservative/up_threshold
echo 30 > /sys/devices/system/cpu/cpu0/cpufreq/conservative/down_threshold
echo 200000 > /sys/devices/system/cpu/cpu0/cpufreq/conservative/sampling_rate
echo 1 > /sys/devices/system/cpu/cpu0/cpufreq/conservative/sampling_down_factor
echo 128000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
#echo 245760 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo 998400 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo 50 > /sys/devices/system/cpu/cpu0/cpufreq/conservative/freq_step
Quite simple.
in build.prop.Code:#CPU echo "conservative" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor echo 70 > /sys/devices/system/cpu/cpu0/cpufreq/conservative/up_threshold echo 30 > /sys/devices/system/cpu/cpu0/cpufreq/conservative/down_threshold echo 200000 > /sys/devices/system/cpu/cpu0/cpufreq/conservative/sampling_rate echo 1 > /sys/devices/system/cpu/cpu0/cpufreq/conservative/sampling_down_factor echo 128000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq #echo 245760 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq echo 998400 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq echo 50 > /sys/devices/system/cpu/cpu0/cpufreq/conservative/freq_step
Change "conservative" to "ondemand", 998400 to 1344000.
Reboot.
Note that I personally find overclock more stable with undervoltage on.
Refer to Phoenix Universal kernel in DSC thread on enabling UV manually.
More, kernel sets high frequencies using 384 and 768 MHz as middle values, so it may be safe using ondemand - TPS chip should handle it.
Also, let's move this discussion elsewhere, as it's off topic here. Thank you.
LuckyPatcher and other programs have a problem with optimized dalvik-cache for classes that aren't verified. So I set up
dalvik.vm.dexopt-flags=v=a,o=v,u=y,m=y
it is like: verify=all dexopt=verified uniprocessor=yes registermaps=yes
Now LuckyPatcher works again, the boot takes not really more time, cache-size is the same as before and this uses register mapping. I'll give it a try a week or two.
have a nice weekend,
hunderteins
getprop | grep dexopt
[dalvik.vm.dexopt-flags]: [v=n,o=a,u=y]
Well, same ~950 in Quadrant (CPU/mem only)
998400
It works with MIUI too but you have to delete the another line that contains
dalvik.vm.dexopt-flags=m=y
i guess this lines value is overlapping with the other lines "u=y" value.
---------- Post added at 08:11 AM ---------- Previous post was at 08:03 AM ----------
The result of first test is:
Productivity index=716
Gaming index=981
with smart bench 2012
---------- Post added at 08:20 AM ---------- Previous post was at 08:11 AM ----------
The result of second test is:
Productivity index=1074
Gaming index=1569
with smart bench 2011