yashsingh1/xdaforums huggingface dataset:
[Galaxy S I9000 General] distortedloop:
I've stated here before, that I respect your contributions and dedication to making the Galaxy S a better device, and I continue to do so, but you often come across as having a particular axe to grind against curio/voodoo and I think you would be better to avoid the broad claims that you often make.

Say "some", or "many", not "most" and you'll avoid the perception by some (or many) that you've got an agenda. You certainly won't get more flak from me about it. :D

Thank you for the eclipse anime example. I will check that out for myself. You're certainly correct that the Galaxy S line is the best mobile video player out there. In the US the Galaxy S advertising on the television is almost exclusively aimed at its wonderful video playback abilities. My dinner party actually got free desserts from a restaurant manager last week as a thank you for showing off the phone's abilities to him; he was so impressed by it! (He's an EVO 4G owner.)
[Galaxy S I9000 General] RyanZA:
Huh? We'r discussing 2 different Voodoo kernels here - they are both supercurio's work? I don't get your point.
[Galaxy S I9000 General] newmail:
I run on the JPK and I didn't have big issues but I didn't use v2.1 much so I don't know the difference well and I come from a slower cellphone....

While playing with strace on the shell I noticed a simple echo foo > bar could take as long as 250msec on the /data partition stalling in close/exit (exit calls close).

That's wrong because there's no O_SYNC or synchronous write at all. So I looked the module and the f_ops->flush operation (FileFlush) called by close is calling write_inode_once(sync=1) unconditionally. I guess just because of that, any other fs is going to be faster than rfs in any common workload that involves writing to a file and closing it... ext4 or any other fs shouldn't make a huge difference on a device so small.

I also increased dirty_ratio to 20 dirty_background ratio to 10 and the dirty_expire_centisecs to 3000 (but that's probably not very helpful with that synchronous write in close) but that's a separate issue and it doesn't make much difference in a device so small.

I searched a bit and I've seen a CONFIG_RFS_SYNC_ON_CLOSE=y config option in some webpage and I assume it's enabled in the rfs module in JPK. That thing is probably what calls write_inode_once(sync=1) on flush and it seems unconditional at compile time. The flush operation don't seem to do anything else than calling that. Any other normal filesystem would also do that synchronous write but only if the file was open by userland with O_SYNC.

It also seems that synchronous inode operation are very slow on rfs, but async cached I/O operations should go as fast as with ext4. I wrote a kernel module to write zero into the flush operation structure of rfs_glue and the 250msec latency is gone, and the test 1/4 of quadrant passes instantly now (previously it was very slow). But the database writes happening later in the I/O test are calling fsync (checked with strace) and they're extremely slow. So I guess it's never going to beat ext4, but not every application that we care about is going to use fsync (sqlite is but sqlite isn't writing all the time I guess).

Quadrant is now at 1020 on my device with stock JPK and flush operation nullified. It's all good as far as I can tell.

Overall I think replacing rfs is the way to go, ext4 likely can't make thing worse than rfs on the hardware considering that fat has fixed positions for the metadata and rfs uses a regular log for the journal (found in some paper in the web). ext4 must be installed directly on the blockdevice not on loop (otherwise I'm unsure if journaling is working right).

If somebody wants to experiment how it feels with the kernel module that allows closes to be asynchronous on rfs I can upload it with the source (if my intuition is wrong it may screw all rfs partitions though). Overall it seems an unnecessary annoyance to be running on a proprietary filesystem that does synchronous writes in close. The only advantage of rfs seems to be the boot time but I don't see people rebooting cellphones very frequently...
[Galaxy S I9000 General] RyanZA:
Wow, awesome! I knew it was something stupid like that! And yeah, no need to load balance on MoviNAND, it has it's own very advanced drive controller that handles all of those types of things.

As far as the kernel module - you say you're using JPK? How did you get the kernel module compiled for JPK? And yeah - we'd like to try it out too! :D
[Galaxy S I9000 General] newmail:
I may understand doing it synchronous for paranoid, but if it was me, I would have never done a synchronous sync on wait. But even if they were paranoid they should have created an option to allow things asynchronous. I'm afraid close isn't the only place where rfs is synchronous.

This only works on the JPK rom, if you don't know which rom you're running don't ever try to load this module as it'll crash your kernel and in the worst case execute random instructions leading to unpredictable feailure!!!! This is guaranteed that it will crash any other kernel in any other ROM, don't ever try loading this hoping that you're lucky, it can only work on JPK!!!!!!

If you try to load this kernel module you do it at your risk. Run insmod rfs_async.ko and it'll return an error (module won't load). Then run "dmesg |grep Success" and you should see it worked. Also I can't guarantee this won't destroy all rfs filesystems (including /efs where the product_code is saved) so use it at your risk. The fact my testing has been ok so far, is absolutely irrelevant, you can't be sure without the source.

To see how I managed to build the modules for JPK see the tun.ko JPK thread. I may generate a diff when I find the time but I hope samsung will release the source soon enough!

In general in the long term we should try to get rid of this rfs and I look forward to run ext4 or some logging filesystem on my /data and /system partitions, so this module is just a test. Luckily the hardware is fast enough that it's not a big deal, I think especially after removing the sync on close.
[Galaxy S I9000 General] distortedloop:
I thought we were discussing two different kernels here - one being curio's custom kernel for "official" voodoo hacks, the other being the "stock" JM8 kernel with voodoo bolted on to it, so to speak. (Note that the "stock" JM8 kernel is an unofficial build from who knows what source that's been leaked.)

Though I thought what we were really discussing was the allegation that excess battery drain is a known issue with "official" voodoo builds. I don't believe that allegation to be accurate, as I've read numerous posts (including my own experience) of no excess battery drain on "official" voodoo, and I've also read at least a few reports of battery life complaints on "stock" JM8 firmware without voodoo. Same story on several other firmwares.

A simple forum search will find battery drain complaints by someone on just about any firmware, or any hack. Voodoo has complainers and, in my opinion, many more non-complainers re: battery life.
[Galaxy S I9000 General] RyanZA:
Not really sure what your point is - you seemed to imply I was just saying that Kernel A was better than Kernel B because I didn't like supercurio. That doesn't make sense, because Kernel A and Kernel B are both supercurio's work. As far as the actual issue, I've done enough tests that I very very firmly believe that the custom kernel version of supercurio's lagfix drains battery faster than the stock kernel version of supercurio's lagfix (of which both kernels have the lagfix by supercurio, with full credits to supercurio for making the lagfix of which is in both kernels). No problem with you disagreeing, but could you provide some tests I could run to confirm that they drain battery at the same rate then?

Again, even if I had something against supercurio, I don't think it comes into the argument of 'supercurio Kernel A' vs 'supercurio Kernel B' ?? ;)

To be honest, at this point this argument between us seems to be just an argument for argument's sake. ;) I'm gonna stop responding now unless you can give some hard data or a test I could try on the battery not being different in standby between 'supercurio Kernel A' and 'supercurio Kernel B', because I don't think I'm convincing anybody who isn't already convinced by this point! Talk about a religious argument, next we'll be onto EXT4 vs EXT2. ;)

EMACS vs VI, distortedloop, which one?! :D
[Galaxy S I9000 General] fane1:
Just my 2 cents here about batt drain.I dont need to test the phone all day to realise that stock voodoojm8 is much better on battery that custom voodoo.this is the second time i switch kernels and there is no doubt to me at least with my phone and aplications i use.Let me say it also that i find custom voodoo a little more faster than stock but i dont mind a little trade must be made.

I understand and accept if other users have different experiments but thats what i feel about both kernels.
[Galaxy S I9000 General] distortedloop:
The root of our disagreement is that you make the sweeping broad statement that it's a well known issue that most people have battery life problems with voodoo. That's not true, or at least not verified in any way, yet you continue to post it.

As far as religious debates; what's my motivation? I have no financial interest in Voodoo. I have no ego interest in Voodoo. Unlike you I offer no competing fixes. I've got no personal issue with you, and have in fact repeatedly stated I have the utmost respect for your contributions to the SGS community.

I am just a user who has tried many of the various fixes for lag and I have found that Voodoo is the easiest to implement, has excellent performance, and has no battery life issues on my phone (and the phones of many others), and I want to make sure that inaccurate charges of bad battery life are challenged. I'd do the same for OCLF if another Dev repeatedly posted in this thread things I knew/thought to be inaccurate about OCLF.

I think that the fact that you offer a competing fix for lag gives you a greater responsibility to be more careful in how you describe or critique other fixes being offered by other devs; others may disagree, but in my opinion, it damages your credibility and is in poor taste. I'd just be more careful about broad generalities.

You continue to confuse with the kernel talk. How is it supercurio kernel a vs supercurio kernel b? My understanding is that you're advocating a "STOCK" kernel (JM8) vs supercurios compiled kernel. If I am misunderstanding that, please identify, by build number, which two compiled kernels from curio that are different that you're talking about. And does this mean that you actually think that there's a supercurio built kernel that doesn't drain batteries.

Emacs vs Vi? Well, whichever one you don't use... :D
[Galaxy S I9000 General] distortedloop:
Posted this separate from the other response so it wouldn't get lost in all the verbosity of the first.

I suppose an easy test would be to download Battery Graph or something similar.

Install "official" voodoo, leave the phone untouched for an appropriate amount of time, recharge the battery, install whatever fix you think uses less battery, leave the phone untouched for an appropriate amount of time in the exact same location as the first test, then compare the two graphs.

You'd have to ensure that all other aspects of the phone are the same for a fair comparison. This would probably mean using a cleanly formatted phone with no apps or widgets or services installed beyond those necessary to get the test running. You'd also have to be able to certify that the cell signal was the same throughout the test.

An app that simultaneously logged signal strength and cpu along with battery state would probably be ideal.

Screen shots from the battery use info screen with each kernel at the end of the test period would be an added plus for comparison.

Any ideas?
[Galaxy S I9000 General] distortedloop:
Obviously I'll have to try it for myself until someone posts a test conducted under appropriate conditions to show what the difference is.

Not attacking your perception, but how much is "much better"? Genuinely curious here. ;)

re: trade-offs, I was a rather vocal advocate against curio's color fix at first, but now that I have it and can turn down the screen brightness from blindingly-bright to just too-bright in a dark room, that's a trade-off that may be hard to make going back to a stock kernel. :(
[Galaxy S I9000 General] RyanZA:
Hahah! :D

Both kernels use supercurio's coded lagfix. They're both fully credited to supercurio. Just cause someone repacked it doesn't mean it's not supercurio's lagfix! I don't understand your whole creditability thing, and I don't really care much for my creditability to start with. I'm here to help people, and telling them that the JM8 kernel has better battery life is helping them - because any tests I've done show that it has better battery life. I'm not going to write a thesis on it or something, in the same way I've not written a thesis on my EXT2 fix being faster than RFS, or a thesis on why Voodoo's EXT4 is faster than RFS. Testing on my device shows it's better. :)

So I've tested JM8-supercurio-voodoo against gpl-supercurio-voodoo and found that JM8-supercurio-voodoo has better battery life. I've recommended it to a lot of people who have tried it, and told me that yes, JM8-supercurio-voodoo has better battery life. You're seriously the only person I know of that disputes it! :D If it damages my credibility in helping people, then so be it. If someone can prove that they have the same battery life (I have no idea how, it's very apparent) then I'll be immediately reversing my position and recommending people use the GPL kernel.
[Galaxy S I9000 General] distortedloop:
It's the kernel, not the lag-fix. LOL.

Yes, the lag-fix in both methods is Curio's. Yes, he's credited by the alternate kernel method, but the kernel is different, right? One is "stock" kernel from JM8 leaked firmware, with the lag fix shoe-horned in with dkcldark's method to load in the modules for ext4 support, right? The other is a compiled from open source for kernel by curio.

Therefore the kernels are not the same, and they're not both from curio, but you kept talking about the kernels, and saying they were both curio's which was the confusion for me, since they're not.

Just to be clear, my argument was never that JM8 stock kernel didn't have better battery life, I have no experience with it to compare; it was the allegation that Voodoo had "known issues with battery life."

Having lesser battery life doesn't make it an "issue", there weren't a lot of complaints about installing voodoo made the phone less usable because of dramatic decreases in battery life. It's an issue if it's lesser to the extent that it negatively impacts usability of the device. Over-clocking your phone will result in lesser battery life, but you'd be hard-pressed to find someone who over-clocks complain that it's an "issue". Same with voodoo.

But this really has reached the point of ridiculousness. End of discussion for me.
[Galaxy S I9000 General] RyanZA:
I seriously have no idea what you're talking about! :D

So anyway I'll sum up for the spectators who don't really care what I think the conclusion is:

Use the JM8-Voodoo instead of the GPL-Voodoo if battery life is important to you! Use the GPL Voodoo if you want the cool colour (and soon to be sound?!) changes. Or something. :D
[Galaxy S I9000 General] distortedloop:
Tsk, tsk, tsk...

Whether by intent or poor phrasing, you continue to try to frame the GPL version in a bad light battery-life wise.

Battery life may be better on JM8, but it's just fine on GPL-voodoo, it's not bad and it's not going to make your phone useless the way your wording suggests.

Other than that nit-pick, I can't disagree with the the rest of the quoted text.
[Galaxy S I9000 General] RyanZA:
Hahah, as you say then! You win! ;)
[Galaxy S I9000 General] newmail:
Stop the madness, to me it looks like battery death is 90% because of the display, wifi, data connection and gps.... And I'm a little addicted and I use many features so, it barely lasts 8 hours for me (at night it consumes almost nothing because it's in sleep).

Unless the kernel changes are very buggy and start spinning in a loop, or they break some pre-existing power feature like cpufreq, it's unlikely any kernel modification to scheduler, I/O scheduler of filesystem will ever be able to be measurable in power terms.... 10 seconds more or less of display on will account more than any kernel change from rfs to ext4 or any scheduler tweak for the whole duration of the battery.
[Galaxy S I9000 General] mib1800:
For the record, I experienced no difference in standby battery life before and after voodoo lagfix (the original one from voodoo website). I am on the JG4 firmware.

So all these "theories" that the original custom voodoo kernel caused a "general" degradation in battery life just does not stand up. So instead of trying to knock the software per-se because your phone experience a degradation, maybe it is more productive to investigate why your particular phone has a problem with voodoo in the first place.

Just my 2-cents.
[Galaxy S I9000 General] distortedloop:
You're both 100% correct.
[Galaxy S I9000 General] newmail:
To make an example I just found csipclient was scheduling in background in a loop every 10msec (a select/gettimeofday loop).... vmstat shows it "cs" column. It makes no sense. Not sure how much it can affect on the battery but I bet a bad userland programming will make more difference than any filesystem change or similar. You install an app and this thing starts at every call even if you don't open it yourself and after that it context switch every 10msec without you noticing. Now I replaced it with a more rudimental but less intrusive sip client that won't ever open unless I tell it to! The accellerometer also schedules a lot but at least it only does that when you've the screen on. But turning off the accellerometer makes most of the context switching go away also when the screen is on. Not sure how much effect it can have over battery life, but at least (probably) the accellerometer case is legitimate to loop :).

If there are severe bugs in the updated kernel of course it can affect battery life. But things like changing filesystem surely can't...
[Galaxy S I9000 General] distortedloop:
The debate's been in the past that the "stock" kernels from the leaked firmwares were almost certainly more optimized, and this optimization resulted in better battery life.

The other, much more religious -like, debate in the lag-fix drama has been whether the journaling on ext4 increased battery drain enough to make ext2 a better choice. There's a whole thread dedicated to that debate, now, though... :)

re: your other interesting comments on battery drainers - that's the key most people miss. They don't do any research and jump to conclusions about what's causing battery drain.
[Galaxy S I9000 General] newmail:
Well the patches are there, I didn't check the whole diff but the core look pretty much unmodified. That's only one core change in blk-core.c which I didn't bother to understand but it looks more driver related than power related. Clearly things like cpufreq and all architecture patches shall be retained... otherwise probably it won't even boot: the patches add a new platform that didn't exist before in the android kernel branch :).

About the ext4 vs ext2, ext4 is a no brainer choice. Ext2 will save a bit of battery in purely theoretical terms (no way to object that as it does less I/O) but you won't ever notice, especially compared to a a "stock" rfs filesystem that issues synchronous writes for every single close syscall! ext4 won't ever be as bad unless of course you mount it with -o sync :). A more interesting debate would be between data=journal mount and a data=ordered mount. I think the default data=ordered is safe enough and it'll avoid trashing the journal blocks too much.

The fat also has fixed location for the metadata, from what I read it seems the journal is a regular journal, so rfs can't assist with the wear out of the flash either (it's not even close to a real logging filesystem that would truly help the flash internal software with the wear out issue).

ext2 would run faster and save a bit of battery on a laptop too, but there's a reason why nobody uses it. I doubt the difference is measurable anyway. It surely won't offset the risk of being without the cellphone for a week during a trip, if it falls and the battery unplugs (it happened to me once with my previous cell, and no it wasn't me holding it when it fall :).
[Galaxy S I9000 General] distortedloop:
You should probably join the debate on that thread; you sound more knowledgable than some posting there. ;)
[Galaxy S I9000 General] RyanZA:
As far as I know, the EXT2 vs EXT4 debate is mostly around performance, and wear on the NAND. Any battery issues are definitely just a side effect!

You seem pretty knowledgeable! :D What you're saying goes against what I was told by some experienced kernel filesystem guy though, so if possible, could you clarify? I was told that EXT2 with a filesystem check on unclean shutdown will be just as data-secure as EXT4 (but obviously could take a long time to do the disk check). Could you clarify why EXT4 would be more data-safe than EXT2? There is a lot of different opinions on this! Thanks! :D
[Galaxy S I9000 General] supercurio:
After months of argumentations, demonstrations, and dozen of years of use.. before that it's a joke right ?
[Galaxy S I9000 General] Oletros:
Can you explain me how a filesystem check can repair data not saved on the filesystem or data corrupted?
[Galaxy S I9000 General] dexteral:
What Lag???

http://www.youtube.com/watch?v=cPU3N4juryk
[Galaxy S I9000 General] RyanZA:
It can't! And neither can EXT4! That's what I've been saying.

Journaling only says 'some data was written to X' - it doesn't say what the data was. You can't recover data from a journal. :) There have been a lot of personal attacks about this, and a lot of repeated 'EXT4 is safe! EXT2 is bad!' but absolutely 0 evidence so far to prove that EXT4 is safer. It would surely be easier to give some evidence than to throw mud around? :)

If you pull out the battery while data is being saved to a file, no amount of journaling or filesystem tricks is going to save that data, since it was never actually on the disk to start with!