[Samsung Galaxy Nexus] bbedward:
No, the main feature of zeneractive is the CPU hotplugging thread.

Just about any % should be safe. Ultimately, the higher unplug_load_cpu1 is the less likely it is to remove a core (as you'd expect). Because it only removes cores <= to that value. 0 basically disables hotplugging, 100 basically means you never want CPU 1 to see the light of day.

Also, load only has to be higher than unplug_load_cpu1 for time = insert_delay to add a core (default there is 80ms). So the higher insert_delay is the less aggressive it is at inserting cores.

Default settings are pretty moderate for removal (they'll get removed at <= 30% after 5 seconds). Default settings for insertion are aggressive, it will add the other CPU very quickly so there is basically no negative performance impact by default.

You don't need to call busybox for sh, as it should already be on your system (you still can though, so theres nothing wrong with that assuming busybox is there)

Also, you need to ensure it has the permissions of an executable (chmod 0755 my_script). And you need to ensure your ramdisk executes all of the scripts in the same directory you have it in (most of the time, /system/etc/init.d), you can look at your /init.rc to make sure it does have a service that calls "run-parts /system/etc/init.d" or something like it.

Also, units on insert_delay and unplug_delay are in microseconds (just like min_sample_time and timer_rate). So default insert_delay is 80,000 (80 ms) and default unplug_delay is 5,000,000 (5 s). So setting them to 100 and 0 is incredible aggressive.

Keep in mind CPU load is not necessarily going to be a smooth curve on its descent/ascent. So, for examples, after 5 timer cycles, the CPU load may be 35, 30, 34, 70, 32. Since your delays are so low are so low (100 uS and 0 s are both basically instantaneous), in that cycle you may see add CPU 1, remove CPU1, add CPU1, remove CPU1 in a matter of seconds/milliseconds (crazy insertion/removal rates). That may be what you want, but just wanted to give you a heads up ;).

The delays are there to keep things a bit sane, also when CPU load goes from 5->30->10 or something, we don't want to add CPU1 in that case which is why the insert delay is there. Consequently, when load goes from 60->5->85, we don't want to remove CPU1 either.

---

My personal suggestions (these are only applicable for our dual core phones of course, on a quad core we'll definitely want to take more into consideration with the unplug loads):

Battery biased

- timer_rate: 40,000 uS (CPU load is calculated in the timer, _not_ the hotplug thread, this means CPU load will change at 1/2 the rate of the default, 20,000 uS)

- unplug_load_cpu1 = 60

- insert_delay = 500,000 uS (1/2 second, less aggressive at inserting cores)

- unplug_delay = 3,000,000 (3 seconds, remove cores faster)

Performance biased

- unplug_load_cpu1 = 20

- insert_delay = 50,000mS (minimally more aggressive than default)

- unplug_delay = 10,000,000 (wait twice as long to remove a core)

Default definitely biases performance slightly, as you may see if you monitor via an app like trickster or something it's very quick to re-add that core. But, since it's relatively new I'm not certain of the best default balance myself yet. That may be up to the users to decide :)

I did decide to remove the suspend/wake code from zeneractive that interactiveX has (so interactiveX may be back in v13). CPUs will still hotplug when the screen is off (but they will hotplug based on load, just like they would when the phone is awake). I may add a "zeneractiveX" with the suspend/wake code (except no hotplugging on suspend/wake, keep it in our thread), but we'll see.