[Galaxy S II Original Android Development] Entropy512:
http://git.kernel.org/?p=linux/kern...it;h=49b015ce38edeb484fb2efa09048c23e903f49d6 from mainline

This, despite your claim, is not part of the Lionheart(X) recipe, unless you're now claiming that patches which were part of the Samsung 2.6.35.7 code drop were applied by you. (This patch is already in the Samsung sources)

Also, for reference, keep in mind we've primarily been speaking about the original Lionheart lately, since it is the one you used as an example to make blatantly false comparisons against other kernels with.

http://git.kernel.org/?p=linux/kern...it;h=fd187aaf980c45f1d16a94a846faa68e24de03c8 from mainline

An actual performance patch - one which you clearly didn't apply. See logic above. Can't apply that which is already there.

http://git.kernel.org/?p=linux/kern...it;h=6dad2a29646ce3792c40cfc52d77e9b65a7bb143 from mainline

Code cleanups, no performance impact whatsoever, just renaming for maintainability. Also clearly not applied by you for the same reason as above. I'm sensing a repeating pattern here...

http://git.kernel.org/?p=linux/kern...it;h=57df5573a56322e6895451f759c19e875252817d from mainline

Small performance increase, if any. Primarily a code cleanup/maintainability patch. This is the first of your listed patches you actually could have applied to the Samsung source tree. Also a patch which most other kernels have...

http://git.kernel.org/?p=linux/kern...it;h=2feb690c20d52e22c7874a1e090245e6a4344ce6 from mainline

100% pure code cleanup, removing a typo that had zero actual effect. Zero performance impact.

http://git.kernel.org/?p=linux/kern...it;h=ef598549b28014ec2ea7574d4e793728e0e33d02 from mainline

Removes a no-longer-used tuning parameter that set an upper limit on the governor polling interval. No performance impact whatsoever unless you are trying to create the "anti-lionheart". e.g. it allows for worse performance but does not change defaults or maximum performance in any way

http://git.kernel.org/?p=linux/kern...it;h=e8951251b89440644a39f2512b4f265973926b41 from mainline

Removes the files that were deprecated by the first patch listed. This has zero performance impact, but improves code maintainability/keeps it clean.

http://git.kernel.org/?p=linux/kern...it;h=326c86deaed54ad1b364fcafe5073f563671eb58 from mainline

This is primarily a code cleanup, removing a bunch of mutex locks no longer necessary due to the previous patch. Removing the mutex locks will have a tiny performance impact when someone alters a tuning parameter - but this is a tiny fraction of a second that happens a few times per boot. It's also insignificant compared to the CPU time of whatever script or app wrote the tuning parameter into the sysfs interface to begin with.

So, at this point, we have a bunch of patches, none of which provide any measurable or worthwhile performance tweaks. Just code cleanups to improve maintainability (which is a worthwhile thing to have).

Now, reordering:

You didn't remove all commented code (I don't believe there even was any), you removed any and all comments whatsoever. Code comments != commented code. Comments are documentation that improves maintainability.

So keep in mind, at this point we have a bunch of patches to improve maintainability and do not affect performance at all.

You just went and threw all that out the window. There is no legitimate reason for removing comments from code. In every case I've seen of comment stripping, it has been by someone trying to obfuscate their code or its origins.

As covered earlier - a variant of netarchy's tuning patch. This one happens to be hardcoded and right up against the limits of the CPU hardware limits.

You got REALLY lucky. After thinking more, I've realized based on observations - I'm fairly certain the Hummingbird's transition latency is around 400 usec considering that Hummingbirds default to 40000 usec sample_rate with the Netarchy patch. So on Nexus S, that patch had over 2x margin from the hardware limitation in the safety code. On Exynos, the default sample_rate is 100000, which indicates the transition latency is 1000 usec, meaning this patch is right at the hardware safety limit in the old code. This came really close to blowing up in your face.

This is where 99+% of the benefits of "lionheart" lie (see previous discussion on why reducing the minimum polling interval is beneficial), and this tuning parameter is exactly what "lionheart tweaks" on other kernels does.

So regardless of the origins of your code, or whether it was stolen or not, this is the ONLY item so far that has any performance impact - and it is a feature that nearly every other kernel currently available has. That is in direct conflict with your claims that Lionheart had something "special" not present anywhere else.

Another blatant lie - anyone can read that patch and see that it applies only to the ondemand governor.

1) We're talking about conservative derivatives here. Now you're just randomly throwing patches in to show off.

2) Even if you had this patch committed, in many (if not all) of your void kernels the ondemand governor is disabled, meaning the patch does NOTHING on them.

Anyone can do this with SetCPU or init.d scripts or whatever they want to use without even patching or recompiling. It does not set your kernel apart from others in any way, or prevent other kernels from matching yours.

Not entirely relevant to the discussion, which stemmed from your false claims regarding the original Lionheart. That said - this gets you 0.1 seconds or so on wakeup compared to using screen-off profiles in SetCPU. Worth the hype? No.

No you won't, because you can't do the above.

Maybe not stolen directly, but clearly inspired considering the end results are EXACTLY the same.

I never said you stole it - but I DID say that despite your claims, these kernels have had the SAME capabilities as yours performance-wise for nearly as long as your kernel existed (Siyah) and before it existed (mine or simone201's codebase). Yet you insist that no other kernel offers the advantages of "lionheart".

I find it hard to believe that patch came from existz, it's too crude. Maybe it did. That said, despite your claims that started this whole thing, every other kernel out there has the same feature. Unlike you, we didn't see fit to rename the governor and hype it up like it was the Second Coming of Jesus Christ Our Savior over one tuning parameter improvement, which is, as covered above, all Lionheart really is. It is clear that you are taking advantage of the placebo effect to make users think your product is better than it really is. If you don't think people here are prone to it - just look at all the people who thought Bravia Engine ports to HTC/Samsung actually did anything. People here will, unfortunately, believe you even if you claim your kernel has mystical tiger blood.

As to arighi's code - yup, you were lying, the code you claim to have patched in could NOT have been patched in to the conservative governor.

Funny, considering you dug your hole even deeper. See above comments reading at least four patches you claim to have applied to the conservative governor, three of which you could not have applied at all because they were already in Samsung's source, one of which could not have been applied to conservative because it's an ondemand-specific change.