vm Tweaks, etc.

[Zach (malaroth)]

And sysctl.conf.... I don't think I've tweaked this one. Once upon a time I did but that was many moons ago.  

http://db.tt/aa8ijX9E

[Chris (osm0sis)]

Do you have anything under /data/local/userinit.d ? The scripts call that as well.

[Chris (osm0sis)]

So far it's pretty sloppy, with a lot of setting stuff over itself; like with 98tweaks, imo's filesys speed tweaks reset some stuff that was set earlier in sourceryfive, and similarly read_ahead_kb is set to 2048 in sourceryfive, then later to 1024 in sdcard, then of course you're setting it to 512 in iosettings.

[Zach (malaroth)]

No.. there's a tmp folder with an init.rc script but no userinit.d

[Zach (malaroth)]

Ah... glad I asked. Those would be my fault. this time around when I flashed back I didn't set those values. But I didn't realize that about imo's script.

[Chris (osm0sis)]

Few things of interest, there's a script that runs zipalign, altering your apks, which can speed some things up, but of course that's only for custom ROMs. sysctl.conf sets some interesting stuff with vfs that Franco might want to take a look at.

vm.dirty_writeback_centisecs=2500
vm.dirty_expire_centisecs=1000
vm.dirty_ratio=90
vm.panic_on_oom=0
vm.dirty_background_ratio=60
vm.page-cluster=3
vm.swappiness=0
vm.vfs_cache_pressure=25
vm.min_free_kbytes=4096
vm.min_free_order_shift=4

I believe they all have sysfs counterparts so we could start playing with them via init.d too.

 

They do some interesting things with cron jobs too, like dropping the vm caches every 8 hours and clearing cache every six hours.

 

Only other things of interest are the (possibly conflicting) fs remounts and "breaking the lease":

 

# Breaking the lease
echo "15" > /proc/sys/fs/lease-break-time

# File system Mounts (By DroidTh3ory?)
busybox mount -o remount,noatime,nodiratime,discard,noauto_da_alloc,nosuid,nodev,data=writeback,barrier=0 -t auto /
busybox mount -o remount,noatime,nodiratime,discard,noauto_da_alloc,nosuid,nodev,data=writeback,barrier=0 -t auto /dev
busybox mount -o remount,noatime,nodiratime,discard,noauto_da_alloc,nosuid,nodev,data=writeback,barrier=0 -t auto /proc
busybox mount -o remount,noatime,nodiratime,discard,noauto_da_alloc,nosuid,nodev,data=writeback,barrier=0 -t auto /sys
busybox mount -o remount,noatime,nodiratime,discard,noauto_da_alloc,nodev,data=writeback,barrier=0 -t auto /system
busybox mount -o remount,noatime,nodiratime,discard,noauto_da_alloc,nosuid,nodev,data=writeback,barrier=0 -t auto /data
busybox mount -o remount,noatime,nodiratime,discard,noauto_da_alloc,nosuid,nodev,data=writeback,barrier=0 -t auto /data/data
busybox mount -o remount,noatime,nodiratime,discard,noauto_da_alloc,nosuid,nodev,data=writeback,barrier=0 -t auto /cache
busybox mount -o remount,noatime,nodiratime,discard,noauto_da_alloc,nosuid,nodev,data=writeback,barrier=0 -t auto /acct
busybox mount -o remount,noatime,nodiratime,discard,noauto_da_alloc,nosuid,nodev,data=writeback,barrier=0 -t auto /dev/pts
busybox mount -o remount,noatime,nodiratime,discard,noauto_da_alloc,nosuid,nodev,data=writeback,barrier=0 -t auto /dev/cpuctl
busybox mount -o remount,noatime,nodiratime,discard,noauto_da_alloc,nosuid,nodev,data=writeback,barrier=0 -t auto /mnt/asec
busybox mount -o remount,noatime,nodiratime,discard,noauto_da_alloc,nosuid,nodev,data=writeback,barrier=0 -t auto /mnt/obb
busybox mount -o remount,noatime,nodiratime,discard,noauto_da_alloc,nosuid,nodev,data=writeback,barrier=0 -t auto /mnt/sdcard

# imoseyon file system speedups
busybox mount -o remount,noatime,barrier=0,nobh /system
busybox mount -o remount,noatime /data
busybox mount -o remount,noatime,barrier=0,nobh /cache

 

[Chris (osm0sis)]

It'd be easy to combine those imo and sourcery remounts by slapping the nobh on the appropriate ones, I honestly have no idea what any of those options do though.

[Zach (malaroth)]

Yeah I'd always used to set the zipalign but I'd never messed with the vmcache except once long ago on 4.1.1 and don't even remember what it was I did. But my phone usually takes no more than 25 seconds or so to boot and then I do have a slight delay as my startup apps load. Cache cleaner and weatherbug and imob battery booster (which doesn't do much for me except it's a longtime habit and I like the percentage battery icon). I've cleaned up the discrepancies with read ahead. I don't know what to do with imo's stuff... I can't delete it. But... like I said I've never had the micro lags and generally don't have reboot or sod unless something is seriously wrong. My phone has always been pretty snappy and honestly... I DO notice a difference in undervolt. Charge time is a lil faster, battery life... well 4.2.2 sucks with battery life and I haven't undervolted since Dec

[Zach (malaroth)]

But this is why I'm so stunned that the row and deadline tunables worked so well.. I literally dug up that guide on xda and studied it for weeks. That's the extent of my knowledge though I have plans to further it now. I don't stop thinking about different variables and cfq has me stumped

[Chris (osm0sis)]

echo 2500 > /proc/sys/vm/dirty_writeback_centisecs;
echo 1000 > /proc/sys/vm/dirty_expire_centisecs;
echo 90 > /proc/sys/vm/dirty_ratio;
echo 60 > /proc/sys/vm/dirty_background_ratio;
echo 4096 > /proc/sys/vm/min_free_kbytes;
echo 4 > /proc/sys/vm/min_free_order_shift;
echo 3 > /proc/sys/vm/page-cluster;
echo 0 > /proc/sys/vm/panic_on_oom;
echo 0 > /proc/sys/vm/swappiness;
echo 25 > /proc/sys/vm/vfs_cache_pressure;

Everything I've learned in the last year about Linux and Android is thanks to xda, franco.Kernel and an itchy Googling finger. Gotta love tweaking. ;)

[Chris (osm0sis)]

Haha so I've already removed these tweaks because they made my device feel slower. Maybe you should do the same Zach; experience franco.Kernel the way it's supposed to be without some ROM dev hijacking the tweaks. ;)

[Steve (Gingerbread Man)]

Would it be a good idea if we were all to run stock rom for the sake of testing?

[Zach (malaroth)]

Already done Chris... ignore my xda pm phone was acting up

[Chris (osm0sis)]

Here's what Khrushy uses for vm:

 

echo 20 > /proc/sys/vm/dirty_ratio
echo 5 > /proc/sys/vm/dirty_background_ratio
echo 200 > /proc/sys/vm/dirty_expire_centisecs
echo 500 > /proc/sys/vm/dirty_writeback_centisecs
echo 0 > /proc/sys/vm/swappiness
echo 300 > /proc/sys/vm/vfs_cache_pressure

 

Tuning the vm might be a good next stop after we're done with cfq.

[Zach (malaroth)]

I'm gonna be testing these vm settings on shiny rom just for my sake. Where I had it on sourcery shiny is about as stock as you can get with a rom with toro. They complain a lot about choppiness and I'm figuring we can draw a bigger test audience. Kinda getting back into my groove, slowly but surely

[Chris (osm0sis)]

mysid JDQ39 OTA dropped if you wanted to try full stock. Factory image should follow soon.

[Zach (malaroth)]

I don't want complete stock. I'm running shiny for the sake of having no interference with Devs playing with stuff they don't understand like in sourcery.
I updated my vm script to mostly like krushys and have it here (dated as well) https://www.dropbox.com/s/kbww7cjoep0a2a0/950vmsettings

[Chris (osm0sis)]

Cool looking into them later today along with hopefully digging up Franco's old iterations. :)

[Chris (osm0sis)]

It's business time gentlemen. ;)

 

I threw in AK Cylon since that's what stevensoaj said our queue tweaks ruined his io speed on. I seem to recall Francisco trying 100 vfs cache at some point as well but I couldn't hunt down the build.

 

Edit: Nevermind stevensoaj, turned out he wasn't using our latest tunables (he had nomerges 1, nr 1024) ;P

 

Seems like these are the vm tweaks we should try out:

/proc/sys/vm/dirty_background_ratio 10 or 5
/proc/sys/vm/dirty_writeback_centisecs 500 or 0
/proc/sys/vm/vfs_cache_pressure 100, 300 or 1

 

VM resources:

https://www.kernel.org/doc/Documentation/sysctl/vm.txt

[Chris (osm0sis)]

New version of the comparison spreadsheet.

 

Also here's the script I used to dump settings from each version if someone wants to use it for other kernels/ROMs. Just type "su -c sh settingsdump.sh" in the same dir as it while booted and output.txt will be created in /sdcard/. I just made it also grab lmk from now on which it didn't before.

 

settingsdump.sh: 

#!/system/bin/sh
 

output=/sdcard/output.txt;
location="/sys/block/mmcblk0/queue /proc/sys/vm /sys/module/lowmemorykiller/parameters";

for target in $location; do
  echo $target/ >> $output;
  for file in $(ls $target); do
    echo `cat $target/$file` $file >> $output;
  done;
  echo -e "\n" >> $output;
done;

 

 

[Zach (malaroth)]

Crazy good job Chris! I could wish these values turned out to be universal, however all I REALLY care about is that they're compatible with Franco. If someone wants to try tweaking values on LK or AK or stock or whatever, then they need to put in the time and effort to find out what the values do, run tests and tweak and document their findings on their own kernel before complaining we Borked their write or read speed. I never intended to discover the IO scheduler Utopia. I intended to take a load off Franco's shoulders so he could focus on more important things. So as long as it works with Franco I'm good

[Chris (osm0sis)]

Same. Just threw in what others were doing for comparison. The Xenon ones are actually the ones imoseyen recommended after looking into them for awhile:

 

http://www.imoseyon.com/2011/02/sysctl-and-minfree-tweaks-revisited.html

[Zach (malaroth)]

OK... at least he's capable of knowing what's what. I've copied over the cron script and zipalign script from sourcery, edited to give credit to sourcery and about to reboot to enable them

[Chris (osm0sis)]

Cool. cron should be nice for drop_caches. Shame busybox for Android doesn't support it out of the box.

 

Got some test vm settings of my own up on http://d-h.st/users/osm0sis now. I feel they help make things pretty smooth and believe I have seen them decrease the frequency and severity of write choking in SD Card Tester. Good high speeds, for the GN, in AndroBench (>27,>7,>6,~0.25, etc.), and lower macro times as well (~120, ~380, ~420, ~1000). I left swappiness in for the sake of placebo even though we don't have ZRAM, and decreased min_free_order_shift to 2 since from my reading it should run better at 1, or close to it on setups with small or no swap.

 

Not really sure about min_free_kbytes though, seemed about the same at 1024, the default 1442, 2048, 2884 (default x 2), 3072, and 4096.

 

/system/etc/init.d/925vmsettings:

#!/system/bin/sh
# chmod -R 755 /system/etc/init.d
# 19-Mar-2013

echo 5 > /proc/sys/vm/dirty_background_ratio;
echo 200 > /proc/sys/vm/dirty_expire_centisecs;

echo 90 > /proc/sys/vm/dirty_ratio;
echo 500 > /proc/sys/vm/dirty_writeback_centisecs;
echo 2048 > /proc/sys/vm/min_free_kbytes;
echo 2 > /proc/sys/vm/min_free_order_shift;
echo 30 > /proc/sys/vm/swappiness;
echo 85 > /proc/sys/vm/vfs_cache_pressure;

 

[Zach (malaroth)]

OK so I've got a couple things... new init.d.zip file with all my scripts. Also krushy was kind enough to share his io settings with fastcharge and scheduler set on boot. Have a look but it's his so give him credit due.
For my zip:
http://db.tt/GWEKpsOg

For krushys settings:
http://db.tt/uXgeha9Q

[Chris (osm0sis)]

Cool. That fastcharge stuff was actually in Franco's 2nd post of the GN thread all along, eh? :P

 

Here's the latest version of the spreadsheet, I added lmk to a second page with Paul's settings and took away queue since we've pretty much got that figured out.

 

Other tweaks I'm interested in exploring with this thread once we've got vm and lmk worked out were the mount options I chopped out of Zach's Sourcery/Imo scripts, and also the entropy and lease-break-time tweaks.

 

 

Edit: Here is a nice reference for the min_free_kbytes value that mforminio7 posted; could be useful:

http://dd.qc.ca/people.redhat.com/kernel/min_free_kbytes.html

 

Also I just noticed he has changed his bdr/dr from 50/70 to 20/50, and min_free_kbytes to 3072 from 4096, so I updated and reattached.

[Paul (pkgnex)]

Thanks for adding my settings.  I think my VM settings are good, but I will admit that my lmk minfree's are not for everyone.  I've been playing with the minfree settings for quite a while, so I think I have a decent handle on what to expect from different settings.  I personally kill empty apps pretty aggressively, and background services moderately.

To me, this makes my phone feel faster when launching apps, browsing, or doing big file reads / writes and is definitely worth it.  Other people will likely be bothered that the app they had open an hour ago got killed off after they did a bunch of other stuff.  I think being aggressive with the minfree stuff is a personal preference for some, but other people will literally hate it.  I will try post what I think would be a more "balanced" set up later, as I doubt my personal settings match that description!

[Paul (pkgnex)]

OK.  Here goes for my promised "balanced" lmk settings:

First, some background:

If you don't know about what these values do, read this first:

http://www.androidcentral.com/fine-tuning-minfree-settings-improving-androids-multi-tasking

Even though it's from 2010 and "android central", it's not bad.  The stock values have changed some, but the principles are the same, and even their recommendations are still relatively sound in terms of only messing with the last two values.  I've seen other info that corroborates this, but not so concise, and not in such plain English.

Anyway, for /sys/module/lowmemorykiller/parameters/minfree, the 4.2.2 AOSP stock values are: 7936, 9984, 12032, 14080, 16128, 20224 pages.  This equates to 31, 39, 47, 55, 63, 79 Mb

Note that stock values works pretty well for most people.  Franco at one time changed the last 2 values to 200.  As I recall, people loved the speed at first, but then got irritated with the latency when re-opening apps they hadn't completely exited (lmk had probably killed them).  This is the expected result, and when Franco returned to stock, nobody really complained about speed, and the "re-opening app latency complainers" went away.  At least, this is how I remember it ;).

I think a very good "balanced" value string that improves (slightly) upon the stock values is: 4096, 8192, 12288, 16384, 32768, 40960 pages.  This equates to 16, 32, 48, 64, 128, 160 Mb

You'll notice that:

- I lowered the minfree slightly for open foreground apps (the first number).  Realistically, this shouldn't really matter because if you have a Nexus and you've got it down to 32 or 16 Mb of free memory available and Android needs to kill the app you are actually presently using, you likely have larger problems!

- I made all the numbers nice "round" numbers (at least multiples of 16 Mb, preferably 32 or even 64).

- I raised the last two numbers - but not to the extent I personally run in my "97pktweaks" script.  The numbers listed above kill empty apps and relatively non-useful background stuff earlier than stock, but not so aggressively that people will be pissed about latency upon re-opening apps, or losing background syncs, etc.  It just frees up a little extra memory from the most useless stuff being held open.  I find that this helps speed up app transitions and opening large apps.  I find that that things start getting killed rather maliciously with the last number at 320, and/or with the 2nd to last number above 192 (192 is marginal).  I push my personal script almost to these values because it suits my usage style rather well (I don't multi-task that much on my phone).

Although I think you should just take my word on these;) feel free to try them out with this command, either with terminal prompt or init.d script:

echo "4096, 8192, 12288, 16384, 32768, 40960" > /sys/module/lowmemorykiller/parameters/minfree

I also highly encourage each of you to try setting the last two numbers really high (like 320 and 384 Mb / 81920 and 98304 pages to be able to experience the trade-off for yourselves.

I hope this helps the lmk tuning discussion.  Let me know if you have any questions, and I'll try to answer them if I can.

[Zach (malaroth)]

Woot! Thank you Paul! I'm trying out the "severe" settings on lmk today, just set them and like you I do prefer more aggressive killing of apps than most. If I'm not currently flipping back and forth between tasks I want them closed and I'll reopen them as needed. Cfq is ale has been a lil daunting to me and I appreciate all of y'alls efforts in that section.

[Chris (osm0sis)]

Got one other minor order of business we need to get out of the way in here before vm, and that's this possible change to the general queue tweaks. Please let me know if it makes a difference having them one way or the other:

 

# general queue tweaks

echo 512 > /sys/block/mmcblk0/queue/nr_requests;
echo 512 > /sys/block/mmcblk0/queue/read_ahead_kb;
echo 2 > /sys/block/mmcblk0/queue/rq_affinity;
echo 0 > /sys/block/mmcblk0/queue/nomerges;
echo 0 > /sys/block/mmcblk0/queue/add_random;
echo 0 > /sys/block/mmcblk0/queue/iostats;
echo 0 > /sys/block/mmcblk0/queue/rotational;

 

or, out to all possible blocks which should theoretically be better?

 

# general queue tweaks
for i in /sys/block/*/queue; do
  echo 512 > $i/nr_requests;
  echo 512 > $i/read_ahead_kb;
  echo 2 > $i/rq_affinity;
  echo 0 > $i/nomerges;
  echo 0 > $i/add_random;
  echo 0 > $i/iostats;
  echo 0 > $i/rotational;
done;

 

 

...Also the entropy thing should be a quick one. I felt increasing the kernel entropy pool size a bit to 128 (default is 64) improves the rand read+write performance just slightly, maybe makes the rand write a bit smoother, and more consistent (in AndroBench).

 

echo 128 > /proc/sys/kernel/random/read_wakeup_threshold;

 

the above seems to be the important one, but there's also write_wakeup_threshold from 128 to 256 (so also doubled) that a lot of people seem to also do but doesn't seem necessary.

 

More on all that here: https://play.google.com/store/apps/details?id=com.zdvdev.sef

[Paul (pkgnex)]

Entropy = good-to-go for me.  I would also add the write_wakeup_threshold doubled to 256... based on the reading I've done that should at least keep the ratios same as stock and reduce the risk of any odd unforseen consequences of having both set the same.

I'm also good with writing the general queue tweaks out to all possible blocks... I'm deferring to your judgment on this one, though.

The long-term plan is for all of this to be put directly into the kernel, removing the need for the add-on scripts, right?

[Chris (osm0sis)]

Thanks Paul, would you mind a quick comparison of the queue tweaks to all blocks vs. just mmcblk0 to see if you feel any differences? Same goes for entropy with benchmarks. Do you get the same feeling about it I do with the rand r+w? Any difference with or without write_threshold? And yes, that's the general plan, though a lot of things are set via the init.rc and init.tuna.rc files and that's perfectly normal for something like entropy and vm. Long run for the schedulers the hope would be Francisco can code those bastards into the source so no need for endless loops.

[Paul (pkgnex)]

I'll try to get to the all blocks vs mmcblk0 eval tomorrow... I've got a project to finish yet tonight :).

As for the entropy, I've evaluated them previously:  I agree that doubling the r&w seems to smooth things out a tiny bit... haven't been able to tell any difference with the write left alone vs also doubled, so I err on the side of caution and just double both so the "3*read - 2*write" (or whatever if I messed that up) relationship for entropy pool fill and depletion stays at least the same ratio as stock.  I've actually been running with these values quite high lately (1024 / 2048) and like it pretty well, but honestly I can't say having the extra entropy available at all times has really done anything for me that the bump to 128 / 256 didn't, so for a general all-user tweak, I think 128 / 256 is the way to go.

[Paul (pkgnex)]

Good news on the all blocks script...  I got it to run (ha ha)!.

First impression, it seems the same to me.  Give me a day with it, and I'll let you know if anything seems different, good or bad.

[Chris (osm0sis)]

Fantastic. Thank you. :) The fill and depletion of entropy seems to almost just be a function of the read_wakeup_threshold though.. 3*read - 1*read, as at 128 it always fills to ~384 (interestingly, tapping the screen fills faster - due to CPU boost or is the kernel actually gaining entropy from touches?.. would be an ingenious seed source for the RNG on non-rotational devices), and then empties to ~256; adjusting write_wakeup_threshold seems to have no effect on it. I can't tell a difference one way or the other.

 

I found my subjective overall feel and semi-objective, perceived differences to bench results petered out at 512 rwt, but I didn't like how much time the idle kernel needed to spend refilling and emptying the pool at anything above 128. Of course at default 64 rwt you never really see the pool move, so I'd imagine it could deplete too quickly at times, so a little bump makes sense.

 

Okay so 128 rwt for sure, and not sure about wwt yet but 256 makes sense even though it has no apparent effects on bench, feel or even entropy. :P

 

Can anyone else tell a difference between wwt at 128 or 256? I'll run at 256 for a day since I've been running at the default 128 for a little while now.

[Paul (pkgnex)]

Been running all day with the general queue tweaks set to all blocks, and there have been no notable negative, or positive effects.

Out of curiosity, what other blocks might be getting written to besides mmcblk9, and what would be using those blocks?  If I understood this better maybe it would be easier for me to just give my final opinion on it.

[Chris (osm0sis)]

Literally nothing that should be getting used that I know of, but you can go into /sys/block/ and see that there are mmcblk0boot0+1 that might perform some function, and assumedly unused mtdblock0 and zram0 blocks. mtd even has a scheduler set so not sure what's up there. Setting the read_ahead_kb might not have any affect on them, but disabling iostats, add_random, and rotational should definitely be smart for possible overhead reductions. I mostly just put the rest of them in for good measure, otherwise they're the same defaults (128 nr, etc.)

 

Edit: Oh yeah, the loops do get used by some apps, and the dm's are created by apps. I think you can busybox mount to see which app's using what. So maybe it'd be a good way to test by seeing if those apps are affected?

 

On my device dm-0 is Cut The Rope :P, dm-1 is f.Ku, dm-3 is HaxSync, dm-4 is Stericson's BusyBox

[Paul (pkgnex)]

Perfect explanation. I agree it makes sense to write to all blocks. I've had no issues with it today. 

[Chris (osm0sis)]

The BusyBox app remains sluggish garbage no matter what. Cut The Rope seemed maybe just a hair faster to load levels. I did notice something interesting with Cut The Rope level loading actually, in switching to original recipe r372 from the osmod build I'm messing with right now I left the Set governor on boot option unchecked and honestly our winning governor settings made a drastic improvement over franco's defaults. Woot evidence, finally. ;)

 

Haha anyway, I guess I'll leave it echoing out to them all since it's clean and simple enough. I'd still like to hear whether a couple more people can feel a difference between entropy 128 rwt/128 wwt, and 128 rwt/256 wwt before we make the call on that.

 

Okay, only other random one I have been saving for this thread before we get into the vm is this:

 

# fs tweaks
echo 15 > /proc/sys/fs/lease-break-time;

Default is 45.

 

Edit: Also, while we're at it, I think we can all agree westwood is by far the fastest/best TCP CA algorithm of those we have available?

[Zach (malaroth)]

Yeah, Westwood is the best by far. Is the lease break time straight forward or is it a boolean? Gonna play with the timing on that

[Chris (osm0sis)]

Actual time in ms I think. So 45 is the default and 15 is what you had in your old init.d scripts. Not sure how big a difference it makes but I figure it's an easy one to look into.

[Paul (pkgnex)]

Westwood or Illinois are the best two.  There are times when one or the other is faster for me (i.e. 4g or WiFi / strong or weak signal), I find myself alternating between them at times.  Both of these are far and away faster than any of the others, though, and Westwood seems to be the popular fav. on this and other kernels.

[Chris (osm0sis)]

Any thoughts on lease time Paul?

[Paul (pkgnex)]

I haven't had a chance to look into it or try different values yet, Os.  Sorry.

[Chris (osm0sis)]

Ah no worries. Thought you might already know a thing or two about it.

Here's what I know about it:

This file specifies the grace period (in seconds) that the kernel grants to a process holding a file lease after it has sent a signal to that process notifying it that another process is waiting to open the file. If the lease holder does not remove or downgrade the lease within this grace period, the kernel forcibly breaks the lease. Defaults to 45.

From Googling it I'm seeing a lot of people using 10 on various devices, Zach's scripts from Sorcery had 15.

Never been a big fan of file locks, knowing blt is in seconds now, I'm also leaning toward 10.

[Zach (malaroth)]

I've actually been running 10 since I asked about it earlier, might even go to 8 or 5 to make quid but I'm liking it better

[Chris (osm0sis)]

Where did you notice a difference? I was having trouble seeing anything tangible.

[Zach (malaroth)]

If I'm using multiple Google apps or apps that access the same functions and am swapping between them they switch quicker with the lowered numbers. Now granted I've been running lease break 15 for about a year so I'm used to it having run sourcery since I got this phone. It's all subjective though I don't have any hard data to point to anything improved

[franciscofranco1990]

VM tweaks... that reminds me when I started to play with Android. Can anyone make me a summary of what has been done so far in this regard and which settings are already considered winning values, if so? VM is a tricky business. I can give some input on this if I know which values have a good standing between you guys.

[Chris (osm0sis)]

We haven't really gotten much going with vm itself yet but you can always check to see what's been finalized over in the Finalized Numbers thread, Francisco. :)

 

P.S. Great to have you back. :D

[Steve (Gingerbread Man)]

Someone just linked this https://code.google.com/p/android/issues/detail?id=40961 which is definatly relevant to this thread, the interesting bit being

build.prop should be:
dalvik.vm.heapgrowthlimit=64m
dalvik.vm.heapsize=384m
(like Nexus 7)

instead of:
dalvik.vm.heapgrowthlimit=96m
dalvik.vm.heapsize=256m

Which apparently brings back the snappines of 4.1. Not tried it yet though.

[Chris (osm0sis)]

Haha was just about to write that. Thanks Steve. :D

Going to try this in 925vm shortly.

Edit: Ah damn, there's no corresponding sysfs for those.. Looking into sysctl.

Edit 2: Nothing there either. So our only hope to not mod the system is with /data/local.prop, it's kinda finicky about what it accepts and how it's written and it doesn't always match the way it is in build.prop.

[Chris (osm0sis)]

Oh duh we can just do it with setprop on boot, easily.

setprop dalvik.vm.heapgrowthlimit 64m
setprop dalvik.vm.heapsize 384m

I'll extract the build.prop from all the old Factory images to double check that guy's findings.

[Steve (Gingerbread Man)]

How did you get on Chris? I editted my build.prop and rebooted and got stuck and Google screen, reflashing now

[Paul (pkgnex)]

I'm trying the "4.1 heap-size values" now, and can't tell any difference... which is what I figured would be the case.

[Chris (osm0sis)]

The setprop commands I posted work perfectly.

 

You can check with:

 

getprop | grep dalvik

 

 

Not sure about impact though.. perhaps a touch quicker? But on the other hand I saw scrolling in widgets get sluggish for the first time in awhile (since 4.1? :P)

[Chris (osm0sis)]

I compared all the build props for the Nexus S, Galaxy Nexus, Nexus 7, Nexus 4 and Nexus 10.

 

The guy was definitely wrong about the second value, it's always been 256 on the GN, not 384 as on the N7. And the first value became 96 only with 4.2 because the dalvik.vm.heap clearly became more complex, and has gradually over time: heapstartsize and heapgrowthlimit were introduced with Android 4.0; and heaptargetutilization, heapminfree and heapmaxfree were introduced with Android 4.2.

 

So what he was talking about was only half the story.

 

It actually went from (takju-imm76i and takju-jzo54k):
dalvik.vm.heapstartsize=8m
dalvik.vm.heapgrowthlimit=64m
dalvik.vm.heapsize=256m

 

To (takju-jdq39):
dalvik.vm.heapstartsize=8m
dalvik.vm.heapgrowthlimit=96m
dalvik.vm.heapsize=256m
dalvik.vm.heaptargetutilization=0.75
dalvik.vm.heapminfree=512k
dalvik.vm.heapmaxfree=8m

 

 

Which makes perfect sense if the actual size is a function of the targetutilization and the growthlimit. 0.75 * 96m = 72m. So if anything, the actual size has only increased by 8m, to 72m from 64m, but now in Android 4.2 it has a further margin to expand if required where it didn't before. Probably a good thing. Programmatically buffers are better than hard limits.

 

If that is the case then setting it to 64 is not the same as reverting to the 4.0-4.1 values, it's actually lowering it to 0.75 * 64 = 48m.

 

 

Anyway, these values are different on each device, clearly depending on how much memory the specific device has, so I don't think they're worth the headache to accommodate or our time to tune when Google clearly knows better than the guy who filed the issue. :P

 

 

Edit: He does have a point that they stayed the same on nakasi between 4.0-4.1 and 4.2 though. But who knows, maybe the N7 is the one that it should have been increased on and the GN is correct.

[Paul (pkgnex)]

Well done, Chris!

On a side note, take a look at my XDA post and file I attached in the BFQ thread - I finally got a reboot on BFQ v6 (after about 5 days of aggregated usage, I'd estimate).

The last_kmsg is attached, and there is definitely some BFQ shit going on shortly before the system went goofy and the kernel panicked.

[Chris (osm0sis)]

Follow-up for any who missed it on xda: The N7 is definitely the odd one out.

These are the values for the N4 and N10:
dalvik.vm.heapgrowthlimit=192m
dalvik.vm.heapsize=512m
dalvik.vm.heaptargetutilization=0.75

0.75 / 2 = 0.375 * 512 = 192.

GN:
dalvik.vm.heapgrowthlimit=96m
dalvik.vm.heapsize=256m
dalvik.vm.heaptargetutilization=0.75

0.75 / 2 = 0.375 * 256 = 96.

N7:
dalvik.vm.heapgrowthlimit=64m <=
dalvik.vm.heapsize=384m
dalvik.vm.heaptargetutilization=0.75

0.75 / 2 = 0.375 * 384 = 144.


Three devices makes a pattern. So however the new implementation of dalvik heapsize works, I think GN people can safely relax because the math for our device matches; we have not been wronged. The N7 on the other hand..

[Chris (osm0sis)]

Trialing the N7 at the higher size according to the math. No immediate noticeable difference, but I'll try it for a few days and see what I think.

 

*cough*

 

hs=`getprop dalvik.vm.heapsize | cut -dm -f1`;
htu=`getprop dalvik.vm.heaptargetutilization`;
hgl=$(( $htu / 2 * $hs ));
setprop dalvik.vm.heapgrowthlimit $hgl'm';

 

;)

 

Edit: Aw shit, shell doesn't support floating point arithmetic, so the 0.75 fails. Looking into it.

 

Edit 2: Here we go. Since busybox doesn't have the 'bc' utitlity that most people use to get around that shell limitation you can do it with 'awk' instead.

 

hs=`getprop dalvik.vm.heapsize | cut -dm -f1`;
htu=`getprop dalvik.vm.heaptargetutilization`;
hgl=`awk -v htu=$htu -v hs=$hs 'BEGIN { print (htu / 2) * hs }'`;
setprop dalvik.vm.heapgrowthlimit $hgl'm';

 

Won't do anything on any of the 3 devices that are already "correct", but will set the N7 (or any device) to the value that Google's current math suggests. Good times! For the N7 that's 144 as I worked out above.

 

Edit 3: Of course, if we think Google's math is wrong, we can change the 2 to a 3 and it will set the GN to 64, N7 to 96. Pretty fun. ;)

[franciscofranco1990]

Shit, a lot of info to swallow!

Should I add this latest shell script to fkbootscript on Grouper?

[Chris (osm0sis)]

No no. Still too early in my opinion. :)

[Chris (osm0sis)]

I'm going to tackle researching the mount options over the next few days. Seems like a reasonably low hanging fruit here. If someone else could try the lease time one we mentioned a while back so we could finalize it that would be great.

[Chris (osm0sis)]

Oh and this for the entropy tweaks so we can finalize those:



''I'd still like to hear whether a couple more people can feel a difference between entropy 128 rwt/128 wwt, and 128 rwt/256 wwt before we make the call on that.''

[Stu (Khrushy)]

Sure, will give both settings a go over the next 4 days. I might be radio silent till Monday night though, as I'm getting away for a few days with the family.

[Paul (pkgnex)]

I changed lease time back to 45 (had been running 10), and I've been having bad luck... May be coincidence, but my widgets seem laggy, play store update had a freeze (first time in a long time) and I had a random freeze and reboot. And I was using noop at the time which has always been very stable for me. Switching to 15, then 10 again to see if I can tell a difference.

[Chris (osm0sis)]

Here is the "light reading" for all the mount options. ;)

 

https://www.kernel.org/doc/Documentation/filesystems/ext4.txt

http://linux.die.net/man/8/mount

http://rootzwiki.com/topic/34994-howto-disable-jellybean-filesystem-check-at-boot/#entry979701

 

Basically I'm considering adding nodiratime,nobh across the board since those were in Zach's old Sourcery scripts and they make sense with data=writeback to improve throughput.

 

For userdata: Since discard doesn't get along with data=writeback in the fstab for userdata (causes bootloops) I say we set it after in fkbootscript.sh, that way nobh and data=writeback can still both be in effect in the stab). Could do this the other way around, not sure which would be more important to have in effect during boot; writeback improves throughput, discard would ensure no newly written data during boot needs to be trimmed later. Now that I type it, I'm thinking perhaps discard would be better during boot to keep the trimming tight. We'll add writeback and nobh via script.

 

For system we should add discard,noauto_da_alloc,barrier=0,nobh,data=writeback - many leave this bare bones since system shouldn't be getting much write action, but hey, we're all power users and using a custom kernel we should make sure it's covered. They do so in AK kernel so meh, why not here?

 

For cache we should add barrier=0 - maybe discard as well, but anarkia seems to think it cany cause slower wake at screen-on? We could try it and see if we agree. If we do agree we could manually trim cache during boot as part of fkbootscript.sh as well.

 

Only one I couldn't find anything on is nomblk_io_submit does, but it's already in both f.K and AK's current fstabs. Here's all I could find on it:

https://android.googlesource.com/device/moto/wingray/+/ec7ac9e0bd315a3e66fec6f72d88f7858e3e02ec%5E!/

 

The end options of wait,check are also included for data and cache on tuna, though not on grouper (3rd "light reading" link) which apparently improves boot times. I could go either way on this one. Not having check can apparently be slightly more trouble if something goes wrong with fsync off, but with fsync on you're all fine and you get much faster boot times, like ICS. Like the guy says, seems like either they removed it on the N7 by mistake, or they forgot to remove it on the GN?

 

Only other thing I'm not sure about is how Zach's script set them for all post-boot mountpoints where the fstab just sets the boot mounts. Not sure if the post-boot mounts get their options from their parent mount or not, worth looking into.

 

 

[Stu (Khrushy)]

Wooo. . . a lot to catch up on.

Please note this isn't a strong preference - I couldn't find a huge amount of difference between the pair, and it was just 5 days of daily driving, no dedicated testing, but I lean towards 128 rwt/256 wwt on that setting.

[Chris (osm0sis)]

Whoops I forgot to include the old fstab and the new one with my proposed changes. Attached.

 

Plus this line into fkbootscript to give us the nobh,data=writeback throughput improvement:

$bb mount -o remount,data=writeback -t auto /data;

 

I think it should keep all the other options from the fstab. I'll make sure. If everyone agrees I'll edit them into the r376 ramdisk and post a tuna test image.

 

Sounds good Stu, I honestly couldn't tell much of a difference between them either. We'll leave 128/256 as final. Thanks. :)

Any thoughts on lease time?

 

 

Edit: AK's fstab for reference - https://raw.github.com/anarkia1976/AK-ramdisk/jb-initram-4.2.2-mainline/ramdisk-4.2/fstab.tuna

[Steve (Gingerbread Man)]

This stuff is getting beyond me at this point, I'm happy to test and give feed back but beyond that I can't do much in this topic. Are these files for init.d?

[Chris (osm0sis)]

Nah it's not too hard if you check those links. I honestly had no idea about what any of it meant before I read them.. They're just options that you can choose to mount the filesystem partitions with, as defined in a file on the ramdisk named fstab.<device>, so for the GN it's fstab.tuna. Some options work together to improve throughput under a variety of loads, some protect from tampering for safety. discard is the big one since it performs trim after the file is deleted, avoiding the I/O slowdowns over time since without it all the free space is still technically full, just marked empty, and a write operation has to empty it first, then write, slowing down writes substantially. They also credit that for the system-wide slowdowns when the flash media gets full. Also worth mentioning I'm just limiting myself to the ones people use anyway - the ones from Zach's Sourcery scripts and the AK fstab. Not getting crazy with stuff we've never seen before.

 

Edit: Sorry, to answer your question directly, no I'll need to replace it in the ramdisk; so I'll need to unpack, replace and repack with that Android Image Kitchen tool I made, to create a new boot.img we can try. That's also how I edited fkbootscript.sh to make "osmod" all those times. :)

[Steve (Gingerbread Man)]

OK well upload a boot.img when its ready and I'll happily try it. Once this gets sorted hopefully Franco can merge it over into the main builds. I'll check out the light reading links when I get proper chance

[Paul (pkgnex)]

Leas time = 10... thumb-up!

45 was giving me issues.  I honestly can't tell a difference between 10 and 15, but 10 seconds for file lease times seems like more than enough to me.

[Chris (osm0sis)]

That's weird that 45 was giving you issues, since that's the default..

 

Zach was saying lowering it should improve things that access the same data, improving some multitasking and so on. Which makes sense.

 

Did you also try 5? Not sure what we'd see if we put it "too low".

[Zach (malaroth)]

I'm running break lease time at five and 10 just feels the smoothest.

[Chris (osm0sis)]

Perfect! 10 it is then. We just got a power outage here while I was in the middle of writing up a big post on what I've discovered about fstab option incompatibilities on tuna.. Sigh.

[Paul (pkgnex)]

I know 45 is the default... and agree it's weird!

My May 2 post above details the "issues."  It may have been coincidence, or maybe it's always been there.  I was running 10 for the last month or so before that (since you first brought lease time up), so maybe I became used to it being better at 10, and the default behavior at 45 no longer felt good.  Don't know.

Anyway, I agree 10 is good to go.  As I said, I've been running it for probably close to two months now, and have no complaints - and personally think changing back to 45 degraded performance on some things.

[Chris (osm0sis)]

Okay so I was going to write a good post about this stuff but I can just sum it up with "fstab is a finicky bitch on tuna" and "busybox is broken garbage" ;)

 

There are only mount option incompatibilities for userdata, and only when setting them in the fstab (ie. these all work fine for system and cache or set later with busybox):

- data=writeback and barrier=0 won't boot past the bootanimation.

- data=writeback and discard cause bootloops (as Francisco saw first hand :P).

- noatime and nodiratime won't boot past the bootanimation.

 

busybox won't set:

- data=writeback stating it's an invalid option.

- noatime or nodiratime at any point before boot completes.

 

So in the end we have to settle for not having nodiratime for userdata since there's no way to set it and noatime is more important (there are more files than directories, usually), and we're forced to set data=writeback in the fstab, so we have to set discard,barrier=0 with busybox in fkbootscript.sh.

 

None of this crap is a problem on grouper, where data=writeback and discard are already both in the fstab together.

 

 

Edit: Tried a newer compile of busybox (stericson's latest - which is 700k to Franco's 1.9mb!), same issues. Oddly even just the built-in mount command seems to have trouble with noatime+nodiratime from in the script. Very weird. nobh also doesn't appear to get set anywhere since it doesn't show up, but it is accepted by the fstab and busybox no problem.

[Chris (osm0sis)]

What the fuck. I've uploaded the boot.img twice now but someone, or something keeps deleting the posts. Not cool. >:|

[Chris (osm0sis)]

Maybe Google takes issue with .sh files being uploaded? I've renamed them to .txt this time.. Anyway, here's what we ended up with. Attached.

I left nobh in the fstab even though it doesn't appear to get set. Maybe on Android it's more of an ext3 (different filesystem type) setting than for ext4 which we use. I also left the nodiratime in the command in fkbootscript.sh in case it randomly starts working sometime. Neither are hurting or anything.

As for the image, I'm uploading to my d-h now in case that's why it's getting auto-deleted. I'll edit with the link in a minute if this post survives. Give it a spin. It's not going to be dramatically different. But I'm curious if you think boot time is faster (since the check is removed like on grouper), and theoretically I/O could be a little faster due to a couple of the added options, and discard should fix the "full sdcard" slowdown. Run fstrim (LagFix Free) one more time on each partition to make sure things are squeaky clean though. :)

 

Also curious if anarkia's thought that discard on cache causes slow wake-up and screen-on is accurate. Seems okay to me so far, so it might be something to do with one of the way-too-many scripts AK installs, one of which, if I recall correctly, trims cache and data every time the screen is turned off.

 

 

Edit: Okay this post stuck. Must have been the boot.img, even though Francisco has certainly never had this problem when uploading one.. Probably IE10's fault. IE9 was much more stable overall and Google Groups seems to be just awful with it.. Either way, here it is: http://d-h.st/xJx

[Chris (osm0sis)]

Only way I can figure out how to get nodiratime set to userdata is later by init.d - BUT the ordering of the busybox commands affects what gets set, it's pretty fucking frustrating. I've made 875mntsettings to help us test another couple ideas I tried:

1) Set noatime and nodiratime to /, /sys, and /proc (the sysfs) for a possible speed up.

2) Same as above but to /storage/emulated/0 etc (sdcard).

The script has a variable set at the top, sdtweaks. First try my boot-r376-fstab.img alone for a bit, then try with 875mntsettings with that variable set to off (so only testing 1), then set it to on and see if you think 2 makes a difference.

 

 

Edit: Attached the init.d script. Adding the if-statement broke it adding nodiratime to userdata because, like I said, it's touchy and defies logic. Anyway that's not important right now. Hopefully once we're done testing the sysfs/sdcard stuff I can remove the if-statement and it'll magically start working again. Note if you aren't using boot-r376-fstab, none of the userdata/cache/system mounts in 875mnt will set entirely correctly either (eg. missing nodev and nodiratime for system, but discard and barrier=0 set fine). It makes no sense.

[Steve (Gingerbread Man)]

After using the boot.img alone since it was uploaded there indeed does seem to be minor performance increase. Boot time is about the same tbh. Gonna see what happens adding in this script now. Nice work

[Stu (Khrushy)]

Glad I didn't mess with anything last night, was tired and couldn't work out how the fstab files were supposed to be used. Come back in this morning, re-read, and realise they're just the changes made to the boot.img that I completely overlooked last night. /facepalm.

Trying the boot.img now, I'll give it a run for a few hours, then add the script in later.

Anything in particular I should be watching for?

[Paul (pkgnex)]

Wow, Chris!

Not sure what it is, but your re-packed kernel feels significantly snappier - especially with the script and the variable turned "on".

I flashed the .img first, and found it felt a little snappier, ran the script next and felt even faster, changed the variable to "on" and force-ran the script again and it felt faster yet. Things like app list loading in the play store "my apps" list, swiping away apps in memory, and switching / opening new Chrome tabs have never felt so fast on my phone (well, maybe if I over-clock the shit out of the CPU).

One note, there may be a "smoothness" trade-off here.  I personally don't care, but I think everything was running so fast that the phone seemed to be getting ahead of itself, if that makes any sense - I got some choppiness/stutter when hitting the back or home soft keys in some apps that I normally don't notice.  I still think overall time to execute the task was actually faster, just what used to be the normal transition animation time now seemed like a lag.  Maybe the CPU or I/O is now significantly outpacing the GPU or something?

Again, I don't care about the smoothness trade-off.  My phone is running the best/fastest it ever has.  Your mods should be in the nightly kernels starting yesterday!

[franciscofranco1990]

But my ramdisk already has writeback mount... using barrier=0 and nobh is a BIG BIG BIG shit... in case of reboot or crash the possibility of having a data corruption is over 9000...

[Chris (osm0sis)]

nobh doesn't even appear to do anything... Doesn't show up in the list when you type "mount" in the terminal. I've left it out for that reason in my newer version I'm playing with right now, so don't worry. ;)

Where is barrier=0 Francisco? Did you set it in a .rc file or something? It doesn't show up and it's not in the fstab.. I was trying to figure out the rc mount syntax to add nodiratime but couldn't get it to do anything.. But that's another story.

You do have writeback of course, but I think you misunderstood me, I was more discussing the incompatibility of writeback and discard on userdata in the fstab that caused those bootloops you saw last time. Those only happen when both are in the fstab, and busybox can't set writeback, so we leave writeback where you had it in the fstab and set discard in fkbootscript.sh instead; problem solved! :D

Like I was saying I discovered, barrier=0 also doesn't get along with writeback with userdata in the fstab, so that's why I added it in the .sh as well.

[Chris (osm0sis)]

Oh wait, you're saying barrier=0 is also a big problem? Hmm. Okay. A *LOT* of people/kernels do.. I can take it out and see how it goes though. What's your take on the "check" stuff, Francisco? It really isn't in the fstab for grouper.

[Paul (pkgnex)]

On r378 now, and I miss the boot-r376-fstab.img already :(.   It was definitely faster in almost every aspect of actual use... but, if data corruption is a possibility, I'm out.

Maybe using the boot-r376-fstab.img was like running with fsync off - which I've never actually done but have heard runs much faster?

At any rate, Chris, if you and Franco can figure this out and verify nothing you did put data integrity at any risk, I think the stuff you had in the fstab file could really take the kernel to a new level!

[Chris (osm0sis)]

Like I said barrier=0 is in every set of tweaks I've seen and a lot of kernels fstabs and ROMs that use init.d scripts. So it must be reasonably safe. For a popular example, it's in the AK fstab and they don't have corruption more than we do. From the documentation, even using writeback alone carries higher risk of data corruption but we've also been doing that for ages. I'd put them on par. Fsync off is a bit different, it's literally telling the machine you don't care about writing out the data it's got in memory in a timely fashion, you just want speed, so keep going. Fsync on blocks further calls until the current operation has written out.

 

I'm running r378 with the 875mnt init.d and it's still pretty crazy fast. I'll edit this post in a few with the important quotes from the docs, once I'm at a PC.

 

 

Edit: Actually with r378 my latest init.d mysteriously seems to be working flawlessly to set all of the options, so if we want to keep testing without modding the fstab looks like it's a go now. Here's a version that lets us also turn off the sysfs tweaks at the top. The only thing we can't set this way is data=writeback to the system partition since busybox thinks the data option is invalid (because it's stupid).

 

Stu, missed your question before, sorry! Just interested in the stuff I wrote in my last post on May 8: If anarkia's wake-up/screen-on issue with discard on cache seems to be apparent for us (I can honestly say it doesn't for me at least), whether boot time seems quicker with the "check" option removed from userdata and cache (maybe a little bit here, but not too noticeably different), and now also whether anything is faster with either the sysfs and/or sdcard tweaks set to "on" from the 875mntsettings init.d I'm attaching.

 

Paul, can you try the latest 875mnt as well and let me know if it's the sdcard or sysfs that makes it seem "too fast" to you?

 

Here's the low-down on barrier=0 (which I am proposing adding) and data=writeback (which has already been in the f.K fstab for a long time):

 

barrier=<0|1(*)> This enables/disables the use of write barriers in barrier(*) the jbd code.  barrier=0 disables, barrier=1 enables. This also requires an IO stack which can support barriers, and if jbd gets an error on a barrier write, it will disable again with a warning.  Write barriers enforce proper on-disk ordering of journal commits, making volatile disk write caches safe to use, at some performance penalty.  If your disks are battery-backed in one way or another, disabling barriers may safely improve performance.

 

data=writeback  Data ordering is not preserved, data may be written into the main file system after its metadata has been committed to the journal. In data=writeback mode, ext4 does not journal data at all.  This mode provides a similar level of journaling as that of XFS, JFS, and ReiserFS in its default mode - metadata journaling.  A crash+recovery can cause incorrect data to appear in files which were written shortly before the crash.  This mode will typically provide the best ext4 performance. (Note  however that running mounted with data=writeback can potentially leave stale data exposed in recently written files in case of an unclean shutdown, which could be a security exposure in some situations.)

 

 

Maybe Francisco can shed a bit more light on the subject, but to me, if we're already not caring about data ordering by setting data=writeback, then we might as well continue to not care about it with barrier=0, especially since barrier=0 is a journaling option and writeback disables journaling, and the fact that our device has a battery. Should be almost totally safe and be our best options to improve throughput.

[Paul (pkgnex)]

Chris,

I think it's the partition tweaks, but the sd tweaks may also contribute.

Running the script with both variables off speeds things up a lot, so that's why I think it's the partition tweaks, since they're outside the variable-controlled if/thens.

Turning the sysfs variable on then doesn't seem to change much (but certainly no detriment), and then turning the sd variable on - with either sysfs on or off - seems to take it up yet another notch.

Nothing objective, just feel-based.

Maybe we should benchmark the various combinations...

[Chris (osm0sis)]

Okay good to know! And remember if you're turning something off you'll have to reboot so that you're starting with a clean slate again. :)

[Paul (pkgnex)]

Oops.  I just force re-ran the script each time (using scriptmanager).

But I think the order in which I ran things (started with all off, then turned on sysfs, then turned on SD before turning anything off) makes it so almost all of my observations in the previous post would still be valid.

[Steve (Gingerbread Man)]

Well using 378 with all 3 init.d scripts we got on the go here, using the 875mntsettings turning SD tweaks on things feel even snappier than before, smoother scrolling and just generally a better faster smoother experience.

Paul, Where you might of found lag at transitions it might be because you have turned up the animation / transitions speeds in dev options? Anyway I'm really pleased with the effect on the pure feel of these I really reckon it would go down great in with the public builds.

[Paul (pkgnex)]

I do have animations sped up to 0.5x, and maybe that has something to do with it.

BTW, I really wasn't meaning to complain about it... I like the speed increase. I really just wanted to point out that it may cause some people to say it feels less smooth.

[Steve (Gingerbread Man)]

I know you weren't don't worry :) I keep the transition speed at what ever stock is for the extra smooooothness as I just don't like how it looks so rushed when you speed it up. Like you said it just looks like it gets ahead of its self too much. Each to their own :)