[Acer Iconia A500] ezterry:
I've maybe seen one blackout since installing v1.0.0 based versions of this kernel.. and it seems to be when your app fails to draw someting in time. This seems to be particular true with some de-odexed roms (since the odex optimization is missing) and some hacked APKs from experimental roms as well as roms for other devices.

Since we have little details (despite the kernel) on what you are running... I can only provide generic android advice.. that seems to be often repeated on deaf ears.

1) When you first boot a rom, allow it to sit for 10 mins to set up the devices properly, search for media ect, failing to do this may provide odd lags for the life of the rom... if you experience said lags in recovery:

A) Clear cache

B) clear dalvik cache

C) fix permissions

(This happens to be the "fixup tab" option in my A500 Public Recovery)

Once this is done reboot and this time do allow it to sit for 10 mins

While some things (particularly if you "downgrade" system applications) benefit from a full wipe.. most issues the above can clear up.

2) The kernel (and this goes for most kernels) is unlikely the [direct] source of your lag, this is because the kernel spends most of its time *not* running. However there are some elements (of this kernel in particular) that can help minimize lag

A) Disk scheduler: this kernel contains two, noop and BFQ, there is a theory that noop is faster on solid state systems since there is no seek time, this theory however in practice is flawed, as solid state devices are frequently slower than ram, thus A large write job can block a small read job, that you require to complete an action. The BFQ implementation in this kernel minimizes the "cost" of rotational disks (since we are solid state) but still allows process to get a better share of the disk IO when multiple operations are happening in parallel. If there is only one operation any scheduler will operate about the same.. but when multiple operations are at the same time BFQ will behave better than noop.. Thus BFQ is the default now but if you switched back to noop you will not get the benefits.

B)CPU governor: Here we have many to choose from but two are really designed with android in mind: Interactive will scale to maximum quickly and slowly scale back down; lulzactive: the implementation provided has two modes normal increase that slowly scales up/down the CPU speed based on the CPU usage, however when the CPU usage is found very high like interactive will force the CPU to max speed before scaling back down. lulzactive ought to be tuned better for battery life, while still providing speed when needed and is in general my recommendation as implemented. That said if you feel you want more speed lowering inc_cpu_load will cause the increases to happen sooner, and increasing pump_up_step will cause the small steps (not when we jump to max) to be larger. (60% may be better for some on inc_cpu_load [default for us is 75%], and you can try 3 on pump_up_speed [default for us is 2]) These changes may slightly reduce battery performance.

3) For some reason the disk IO is particularly slow on the Iconia... some of this can be fixed via remounting /data with different mount options some details here

4) One last thing to remember.. the Nexus S is a 480 x 800 device (384000 total pixels) we are a 1280x800 device (1024000 total pixels) or about 3x the display data. This means there are things applications for the Nexus S can get away with that become notably more complex when the same application is on the a500. Not saying the right balance of using hardware and software can't correct this.. but it needs to be built into the applications and/or framework and not the Linux kernel.

Beyond these hints there is a limit without detailed logs, even then it is frequently difficult as I'm not seeing the issues first hand, unless we are lucky and find a way for me to re-produce the issue. However with the logs I can at least compare your device to mine (There are a few different lines of a500 with similar but not quite identical hardware.. its possible the kernel has some bugs that apply to your line and not to mine) This is one reason I sometimes ask for the dmesg just after boot in addition to the log with actual errors, Is I can compare the start up to my device, and others, to see any hardware differences.

Note for reference.. about 500 people so far have downloaded the v1.0.0 kernel, not included those using it built into the FLEXREAPER rom, or the a100 version, overall very few reported issues.