• After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.

Root [STOCK][LINARO 4.9.3] Volt Uno v3.3

Attachments

  • 1449257652227.jpg
    1449257652227.jpg
    52.7 KB · Views: 93
Hmm... There aren't really any massive differences. I guess it's not really that significant.
The biggest variance is your RAM speed. What governor/read ahead buffer are you using?
 
bg4m3r said:
Hmm... There aren't really any massive differences. I guess it's not really that significant.
The biggest variance is your RAM speed. What governor/read ahead buffer are you using?
Click to expand...
I assume you mean i/o scheduler. SIO and 2048kb. However, that should only make a difference for Storage I/O and have absolutely no affect on RAM, unless you're using SWAP. In which case, I'd say disable it for benchmarking.
 
spock1104 said:
I assume you mean i/o scheduler. SIO and 2048kb. However, that should only make a difference for Storage I/O and have absolutely no affect on RAM, unless you're using SWAP. In which case, I'd say disable it for benchmarking.
Click to expand...
Yeah, that's what I'm talking about. For some reason I keep wanting that to be for RAM... and I am using swap, so I guess that might be the issue there.
 
Ok I downloaded Ubuntu 14.04 and installed it into a VirtualBox machine. Followed everything at https://source.android.com/source/initializing.html to set it up. No more issues during compile but afterwards I get kernel I cannot boot. How are you taking the zImage and dtb files and merging it into a boot.img? Whatever is in the Volt Uno Tool Kit isn't working for me.

EDIT: Oh and if I just compile as normal from the 'duo' branch using only your config file without enabling any extra configurations the output is fine and does boot. I feel like I'm missing something but I just cannot figure it out, no matter how much I search online. It seems if the file is too big it will not boot, i.e. your configuration builds on my system and outputs 14.8MB on my comp but my build comes out to 14.9MB (I just enabled /proc/config.gz for a test)
 
Last edited:
Ok so maybe it's not exactly how I'm compiling but the features I wanted to enable. Could you check for me @spock1104? My base test, the one thing I thought I could safely enable without problems was config_ikconfig proc=y which I understood was to allow one to view the config file for what features were turned on in kernel after compiling. The other things I tried to enable separately were, config_binfmt_msic=y , config_zram=y ; and lastly config_usb_ehci_msm_hsic=y (in hopes to enable OTG, other configs from different kernels has this one enabled).

If nothing else get things like KSM and Zram working to help out the low RAM issue.
 
ShapeShifter499 said:
Ok I downloaded Ubuntu 14.04 and installed it into a VirtualBox machine. Followed everything at https://source.android.com/source/initializing.html to set it up. No more issues during compile but afterwards I get kernel I cannot boot. How are you taking the zImage and dtb files and merging it into a boot.img? Whatever is in the Volt Uno Tool Kit isn't working for me.

EDIT: Oh and if I just compile as normal from the 'duo' branch using only your config file without enabling any extra configurations the output is fine and does boot. I feel like I'm missing something but I just cannot figure it out, no matter how much I search online. It seems if the file is too big it will not boot, i.e. your configuration builds on my system and outputs 14.8MB on my comp but my build comes out to 14.9MB (I just enabled /proc/config.gz for a test)
Click to expand...

I've been having this issue depending on what I enable. It's been very frustrating, don't know how to address it yet. You can try either removing some of the optimizations I added to the Makefile, or switch on optimize for size in the config. Consequence is the kernel won't perform as fast but the reduction should be minimal.

bg4m3r said:
I would like to have intellidemand CPU governor also.

Most importantly... Please, if you have a chance. THANK YOU :)
Click to expand...

Because of the above, I'm not sure if I can even get it working. I will say though that faux123 obsoleted intellidemand with intelliactive, so I suggest giving that one a try for now and let me know after a few days use if you're still interested in intellidemand.

Thanks for the feedback guys.
 
spock1104 said:
I will say though that faux123 obsoleted intellidemand with intelliactive, so I suggest giving that one a try for now and let me know after a few days use if you're still interested in intellidemand.

Thanks for the feedback guys.
Click to expand...
OK, I wasn't aware of that. Didn't you say at one point not to use intelliactive? Or was that just for when benchmarking?

Also, can you explain the two temperature options? I can't seem to find any info about Core Control.
 
bg4m3r said:
OK, I wasn't aware of that. Didn't you say at one point not to use intelliactive? Or was that just for when benchmarking?

Also, can you explain the two temperature options? I can't seem to find any info about Core Control.
Click to expand...

That's just for benchmarking, using the performance governor on every benchmark guarantees a uniform benchmark across all kernels. If you use another governor or have mpdecision/intelliplug enabled you introduce the bias of whatever those functions do to save power (i.e. balancing your cpu load).

I'm not sure what the temperature options are, only that I'll be adding another at some point :-P.
 
spock1104 said:
I've been having this issue depending on what I enable. It's been very frustrating, don't know how to address it yet. You can try either removing some of the optimizations I added to the Makefile, or switch on optimize for size in the config. Consequence is the kernel won't perform as fast but the reduction should be minimal.
Click to expand...

You just saved me about a day or two of research on this issue, thank you. I had eyed the config_cc_optimize_for_size option but I wasn't sure it was the correct thing to be enabling. New kernel compiled and got zram, ksm, and binfmt_misc all working. Everything except for zram is built in, I left zram as a module for more flexibility on how many zram devices you can create. The idea floating around online has been 1 zram device per cpu core, for the LG Volt that would be 4 zram slots. I have to say my device crashed once when I gave zram to much ram, seems stable with 16mb per device for a total of 64mb zram.

Here is the compiled kernel in case someone wants to mess around and test it. https://www.androidfilehost.com/?fid=24269982087013540
 
ShapeShifter499 said:
You just saved me about a day or two of research on this issue, thank you. I had eyed the config_cc_optimize_for_size option but I wasn't sure it was the correct thing to be enabling. New kernel compiled and got zram, ksm, and binfmt_misc all working. Everything except for zram is built in, I left zram as a module for more flexibility on how many zram devices you can create. The idea floating around online has been 1 zram device per cpu core, for the LG Volt that would be 4 zram slots. I have to say my device crashed once when I gave zram to much ram, seems stable with 16mb per device for a total of 64mb zram.

Here is the compiled kernel in case someone wants to mess around and test it. https://www.androidfilehost.com/?fid=24269982087013540
Click to expand...
What did you use to set up zram?
 
The new build is working well. I found an app to enable zram, although it doesn't allow me to create multiple zram devices or set the size. Would like to know how to configure these.
 
This is the script I'm using to initialize zram at boot. Just save the script below under /etc/init.d/ and tweak the zdevice and zsize variables to your liking.

Code: 
#!/system/bin/sh

# Specify number of devices usually one per cpu core.
zdevices=4

# Specify total zram size in megabytes which will be split by number of zram devices.
zsize=128

# Swappiness value, 100 makes sense but you decide
swappiness=100

# Load module
insmod /system/lib/modules/zram.ko num_devices=$zdevices

# Set up the devices

zsize=$(($zsize * 1024 * 1024))
zsize=$(($zsize / $zdevices))

i=0
while [ $i -lt $zdevices ]
do
echo $zsize > /sys/block/zram$i/disksize
mkswap /dev/block/zram$i
i=$(($i + 1))
done

# Wait for system to load completely.
while [ -z "$(pidof com.ra3al.launcher)" ]; do sleep 2; done
while [ -z "$(pidof com.android.systemui)" ]; do sleep 10; done

sleep 10

# Enable zram as compressed swap, keep all zram devices the same swap priority for speed.
i=0
while [ $i -lt $zdevices ]
do
swapon -p 3 /dev/block/zram$i
i=$(( $i + 1 ))
done

# Change swappiness value.
echo $swappiness > /proc/sys/vm/swappiness

EDIT: Typo was in the zram script above, fixed now. DOUBLE CHECK YOU HAVE IT CORRECT PLEASE.

EDIT 2: Don't try to give zram more than the amount of ram available (863Mb according to the 'free' command), it will cause a kernel panic.
 
Last edited:
I made one change to my script above. Because I found app tweakers like 'kernel adiutor' will mess with the first zram device (zram0) if you turn on the 'virtual memory' section to be applied on boot, you have to set things like swappiness manually. Oh and feel free to take, share, and modify my script above as you see fit.
 
bg4m3r said:
The new build is working well. I found an app to enable zram, although it doesn't allow me to create multiple zram devices or set the size. Would like to know how to configure these.
Click to expand...
Because zram is commonly compiled in kernel instead of as a module it only gets one zram device at any time and cannot be changed. That's why most zram apps and tweak apps provide settings for only one zram device. I'm not sure why one zram device would be preferred over making more than one.
 
ShapeShifter499 said:
Because zram is commonly compiled in kernel instead of as a module it only gets one zram device at any time and cannot be changed. That's why most zram apps and tweak apps provide settings for only one zram device. I'm not sure why one zram device would be preferred over making more than one.
Click to expand...
Maybe clinging to old premulticore concepts? Anyway, installed your script. Kernel Adiutor actually shows a zram section in the Virtual Memory section now that allows you to change the size (I don't think enabling it with the other app triggered that, of course, it never even asked for root, so who knows if it was even working). However, based on your warnings I just turned off that section (I hadn't had it enabled anyway) so it doesn't even display and set size in the script (I went with 80MB total, approx 1/10 of the total RAM and set swappiness to match what I set for swap [75] to avoid an argument). It seems to be playing nicely with the swap script as well so far. :)

So glad you took up the reins on this kernel!

I don't get why Zram wasn't included in the stock kernel?
 
Last edited:
By
bg4m3r said:
Maybe clinging to old premulticore concepts? Anyway, installed your script. Kernel Adiutor actually shows a zram section in the Virtual Memory section now that allows you to change the size (I don't think enabling it with the other app triggered that, of course, it never even asked for root, so who knows if it was even working). However, based on your warnings I just turned off that section (I hadn't had it enabled anyway) so it doesn't even display and set size in the script (I went with 80MB total, approx 1/10 of the total RAM and set swappiness to match what I set for swap [75] to avoid an argument). It seems to be playing nicely with the swap script as well so far. :)

So glad you took up the reins on this kernel!

I don't get why Zram wasn't included in the stock kernel?
Click to expand...
Because 1gb of memory is still plenty for now unless you have an app with absurd demands. Zram sacrifices CPU time to be able to fit more into memory. Swap sacrifices CPU and sdcard life time to create a slow memory alternative. So in most cases it just creates a slower phone, and including it in the kernel increases the kernel's size and memory footprint.
 
spock1104 said:
By
Because 1gb of memory is still plenty for now unless you have an app with absurd demands. Zram sacrifices CPU time to be able to fit more into memory. Swap sacrifices CPU and sdcard life time to create a slow memory alternative. So in most cases it just creates a slower phone, and including it in the kernel increases the kernel's size and memory footprint.
Click to expand...
Well, I've seen nothing but improvement here.
 
I'm not trying to suggest there won't be improvement, I'm just saying that for most use cases improvements wouldn't be expected, and hence why LG would have left them out.
 
You must log in or register to reply here.
Back
Top Bottom