[KERNEL][AOSP/TW][27 Dec] War Kernel r3 // colder than ever

[I_android]

firstly, andobench results are hardly repeatable.

also, trim capable kernels are absolutely NOT in any way different than noncapable ones, except when you actually execute a trim command (ie: it works).

if you want to compare apples to apples, compare one of my trim kernels against my corresponding fpbug-only non-trim version.

some ramdisks might be mounting partitions with the DISCARD mount option. this transparently trims on a trim kernel and not on others, introducing differences. DISCARD should not be used in android 4.3+, as it decreases performance and android 4.3+ has an "offline" trim feature. my kernels do not mount with DISCARD.

but again, the highest factor is probably androbench's randomness.

Thanks for replying.

Well I 100% agree with your view point, to different kernel's results can't be compared that way. Only thing I wanted to point out is forest1971 and GeeckoDev is doing something differently and bauner is doing differently apart from Trim support, that's why there is such a huge difference in the results.

And I would really love to try out your kernel, however unfortunately your kernel is not available for Lollipop CM12. Do you have any plans to release one for CM12?
Thanks.

 

[Lanchon]

Thanks for replying.

Well I 100% agree with your view point, to different kernel's results can't be compared that way. Only thing I wanted to point out is forest1971 and GeeckoDev is doing something differently and bauner is doing differently apart from Trim support, that's why there is such a huge difference in the results.

And I would really love to try out your kernel, however unfortunately your kernel is not available for Lollipop CM12. Do you have any plans to release one for CM12?
Thanks.

no. my kernel is trivially modded from CM's. there's no official CM12 kernel for exynos 4 (so i can't do mine), and fpbug fix has been merged (so there is no reason for me to do it anyway). if official cm12 releases, ill do a trim version of it.

i insist that it all *could* be an artifact of androbench. if you run the bench 3 times on each kernel and results match, only then IMHO it'd be worth it for the involved individuals to investigate.

 

[GeeckoDev]

no. my kernel is trivially modded from CM's. there's no official CM12 kernel for exynos 4 (so i can't do mine), and fpbug fix has been merged (so there is no reason for me to do it anyway). if official cm12 releases, ill do a trim version of it.

i insist that it all *could* be an artifact of androbench. if you run the bench 3 times on each kernel and results match, only then IMHO it'd be worth it for the involved individuals to investigate.

bauner's kernel outperforms the other two because of dynamic fsync. There's no way the eMMC could pull a real 200+mb/s for writing. It's cached.

 

[I_android]

no. my kernel is trivially modded from CM's. there's no official CM12 kernel for exynos 4 (so i can't do mine), and fpbug fix has been merged (so there is no reason for me to do it anyway). if official cm12 releases, ill do a trim version of it.

i insist that it all *could* be an artifact of androbench. if you run the bench 3 times on each kernel and results match, only then IMHO it'd be worth it for the involved individuals to investigate.

Well I did run test multiple times on each kernel (before trim, after trim, just after restart, after using phone for couple of hours etc), all the tests gave me nearly same results for that particular kernel. I just uploaded only one screenshot from each kernel just to show the results to all the Devs. If you want to see those multiple results I can upload all of them. But trust me they all are nearly same.

---------- Post added at 05:47 PM ---------- Previous post was at 05:41 PM ----------

bauner's kernel outperforms the other two because of dynamic fsync. There's no way the eMMC could pull a real 200+mb/s for writing. It's cached.

Well I do agree that 200+ mb/s is very high as far as writing is concerned. But I don't know how cache be involved while writing data to disk or to DB. While reading yes cached data can be used however. That's my knowledge with development I do in Java (not Android related though)
@bauner
please share your view point on the subject.

 

[Lanchon]

bauner's kernel outperforms the other two because of dynamic fsync. There's no way the eMMC could pull a real 200+mb/s for writing. It's cached.

lol! i never even opened the screenshots to look!

disabling fsync is extremely dangerous for your data and partitions. i wouldnt use any kernel from someone who disables fsync, i just couldnt trust their judgement at all. IMHO disabling fsync is something al-qaeda would do lol!

btw, is there any way to replace fsync's implememtation with write barriers so that writes are performed asynchronously but data consistency is preserved?

---------- Post added at 09:43 AM ---------- Previous post was at 09:41 AM ----------

Well I do agree that 200+ mb/s is very high as far as writing is concerned. But I don't know how cache be involved while writing data to disk or to DB. While reading yes cached data can be used however. That's my knowledge with development I do in Java (not Android related though)
@bauner
please share your view point on the subject.

google write-back cache

 

[GeeckoDev]

Well I do agree that 200+ mb/s is very high as far as writing is concerned. But I don't know how cache be involved while writing data to disk or to DB. While reading yes cached data can be used however. That's my knowledge with development I do in Java (not Android related though)

Here's a better explanation.

'man fsync' says:

The fsync() function shall request that all data for the open file descriptor named by fildes is to be transferred to the storage device associated with the file described by fildes. The nature of the transfer is implementation-defined. The fsync() function shall not return until the system has completed that action or until an error is detected.

In other words, it forces the operating system to flush buffers and write all the data to the disk. dynamic fsync just makes this function non-blocking when the screen is ON, effectively reducing lag in some applications. However, this can be dangerous because data integrity is not assured anymore.
Furthermore, it has a drastic effect on synthetic benchmarks. These applications HAVE to use fsync to ensure all data is written to the disk and calculate its speed. But if fsync returns immediately, the benchmark will think the device is much faster than it is really, hence the 200+mb/s write speed.

lol! i never even opened the screenshots to look!

disabling fsync is extremely dangerous for your data and partitions. i wouldnt use any kernel from someone who disables fsync, i just couldnt trust their judgement at all. IMHO disabling fsync is something al-qaeda would do lol!

btw, is there any way to replace fsync's implememtation with write barriers so that writes are performed asynchronously but data consistency is preserved?

I agree. TIL @bauner belongs to Al-Qaeda. :laugh:

Nah really, I think it would be better if NightOwl shipped with a untouched kernel, except FPBug and TRIM fixes merged. No -Ofast, dyn fsync or other aggressive optimizations.

 

[I_android]

lol! i never even opened the screenshots to look!

disabling fsync is extremely dangerous for your data and partitions. i wouldnt use any kernel from someone who disables fsync, i just couldnt trust their judgement at all. IMHO disabling fsync is something al-qaeda would do lol!

btw, is there any way to replace fsync's implememtation with write barriers so that writes are performed asynchronously but data consistency is preserved?

---------- Post added at 09:43 AM ---------- Previous post was at 09:41 AM ----------



google write-back cache

Thanks a lot... write-back cache, I know that...I didn't think of it when I read GeeckoDev comment.
But this is like writing data to cache and not to disk or to DB. Which is very risky.

---------- Post added at 07:00 PM ---------- Previous post was at 06:56 PM ----------

Here's a better explanation.

'man fsync' says:


In other words, it forces the operating system to flush buffers and write all the data to the disk. dynamic fsync just makes this function non-blocking when the screen is ON, effectively reducing lag in some applications. However, this can be dangerous because data integrity is not assured anymore.
Furthermore, it has a drastic effect on synthetic benchmarks. These applications HAVE to use fsync to ensure all data is written to the disk and calculate its speed. But if fsync returns immediately, the benchmark will think the device is much faster than it is really, hence the 200+mb/s write speed.



I agree.

understood it very well thanks for explanation...it was a good learning

---------- Post added at 07:03 PM ---------- Previous post was at 07:00 PM ----------

@bauner
We are eagerly waiting for you to comment on above discussions. Is fsync disabled in beta4 stock kernel?

 

[GeeckoDev]

Announcing Raw Kernel r5 for Touchwiz

Changes over r4/TW :
* Latest FPBug patchset merged
* TRIM-enabled
* -fno-pic build to fix recovery
* -50mV GPU downvolt for group B+

Only compatible with Touchwiz roms. r3p1 blobs + libc.so included.

Download :
* raw_kernel_r5_tw.zip
* raw_kernel_r5_tw_59hz.zip (59hz build for S-Pen users, and no screen flash when offline charging)

This is likely the last TW release because I'm switching over to Lollipop as my daily driver. It's been a great time!

 

[bauner]

Nah really, I think it would be better if NightOwl shipped with a untouched kernel, except FPBug and TRIM fixes merged. No -Ofast, dyn fsync or other aggressive optimizations.

The kernel is build with -Os in the NightOwl Roms.
I know that disabling fsync is very dangerous for data integrity.
But for me dyn fsync was an acceptable way for speedup with an bit lower risk for data corruption.

But I agree that such potentially dangerous optimizations should not shipped in the default kernel for all day use.

In the next beta5 I will remove dyn fsync and will provide an alternate kernel for such crazy users like me.

For now if you don't want to use dyn fsync you can disable it with "echo 0 > /sys/kernel/dyn_fsync/Dyn_fsync_active"

 

[Macrint]

Just flashed r5 tw and testing it now. Thanks again!

 

[GeeckoDev]

The kernel is build with -Os in the NightOwl Roms.
I know that disabling fsync is very dangerous for data integrity.
But for me dyn fsync was an acceptable way for speedup with an bit lower risk for data corruption.

But I agree that such potentially dangerous optimizations should not shipped in the default kernel for all day use.

In the next beta5 I will remove dyn fsync and will provide an alternate kernel for such crazy users like me.

For now if you don't want to use dyn fsync you can disable it with "echo 0 > /sys/kernel/dyn_fsync/Dyn_fsync_active"

Great! Way to go bauner! :good:

-Os build is interesting for embedded devices that have a very small cache, but I doubt it's useful for a dual Cortex A9 chip.

 

[ThaiDai]

I installed the latest TW version and get the same error as with v4 in Avast Firewall.

When I try to activate this firewall I get this message (original in german):
Error when applying the firewall rules (Code 1). dmesg: klogctl:
Function not implemented

With the original kernel no problem. @GeeckoDev: Is something missing in the kernel or in the firewall implementation?

 

[GeeckoDev]

I installed the latest TW version and get the same error as with v4 in Avast Firewall.

When I try to activate this firewall I get this message (original in german):
Error when applying the firewall rules (Code 1). dmesg: klogctl:
Function not implemented

With the original kernel no problem. @GeeckoDev: Is something missing in the kernel or in the firewall implementation?

It seems Avast depends on dmesg, which is disabled because this kernel is based on c.o.h's HelloWorld sources.

 

[ThaiDai]

It seems Avast depends on dmesg, which is disabled because this kernel is based on c.o.h's HelloWorld sources.

Thanks. So I have to look for a different firewall. If I do not find a suitable one then I have to switch back (but I do not want to do this).

 

[cheaterdawaq]

Hello @GeeckoDev Thanks for the new release. This will be the first time that I'm going to use TRIM, so I'll still ask, can I use your flashable zip (run_fstrim.zip) on r5 TW?

 

[phoenX80]

I believe this zip is only initiating terminal commands - so its not a classical "flash" in its sense. So it should work an any trim kernel in my opinion.

Sent from my Nexus 4 using XDA Free mobile app

 

[GeeckoDev]

Hello @GeeckoDev Thanks for the new release. This will be the first time that I'm going to use TRIM, so I'll still ask, can I use your flashable zip (run_fstrim.zip) on r5 TW?

You can use it on any kernel, but it will do nothing if the kernel doesn't support TRIM.

I believe this zip is only initiating terminal commands - so its not a classical "flash" in its sense. So it should work an any trim kernel in my opinion.

Yep it doesn't flash anything, see the script:

ui_print("Mounting partitions ...");
run_program("/sbin/busybox", "mount", "/system");
run_program("/sbin/busybox", "mount", "/cache");
run_program("/sbin/busybox", "mount", "/data");
run_program("/sbin/busybox", "mount", "/preload");
show_progress(0.200000, 0);
ui_print("Trimming /system ...");
run_program("/system/xbin/fstrim", "-v", "/system");
show_progress(0.400000, 0);
ui_print("Trimming /cache ...");
run_program("/system/xbin/fstrim", "-v", "/cache");
show_progress(0.600000, 0);
ui_print("Trimming /data ...");
run_program("/system/xbin/fstrim", "-v", "/data");
show_progress(0.800000, 0);
ui_print("Trimming /preload ...");
run_program("/system/xbin/fstrim", "-v", "/preload");
show_progress(1.000000, 0);
unmount("/system");
# /cache stays usually mounted in the recovery
unmount("/data");
unmount("/preload");
ui_print("Done.");

 

[BarelyPosting]

Hello @GeeckoDev Thanks for the new release. This will be the first time that I'm going to use TRIM, so I'll still ask, can I use your flashable zip (run_fstrim.zip) on r5 TW?

Yes yes you can. I already did it. It works perfectly.

@GeeckoDev Thanks for the last release of TW Kernel. I think I'm going to stick with TW as my daily driver. Since it will be the last, can I have a last request too for R5/TW? Can you release a last separate version of r5/TW with all the features included but with OC GPU (just the GPU 160-267-400mhz)? It seems that no one released an overclocked GPU after updating the mali driver (blobs - 4.2) since it's not needed anymore. Though I really want to try it for gaming purposes, just for the sake of gaming. lol I also noticed that every time I try using your kernel, it seems that it is more vivid and vibrant in color compared to most kernels, or is it just my imagination? Well anyway, thank you in advance. Good luck to your kernel development for KK and LP ROMs!

 

[GeeckoDev]

Yes yes you can. I already did it. It works perfectly.

@GeeckoDev Thanks for the last release of TW Kernel. I think I'm going to stick with TW as my daily driver. Since it will be the last, can I have a last request too for R5/TW? Can you release a last separate version of r5/TW with all the features included but with OC GPU (just the GPU 160-267-400mhz)? It seems that no one released an overclocked GPU after updating the mali driver (blobs - 4.2) since it's not needed anymore. Though I really want to try it for gaming purposes, just for the sake of gaming. lol I also noticed that every time I try using your kernel, it seems that it is more vivid and vibrant in color compared to most kernels, or is it just my imagination? Well anyway, thank you in advance. Good luck to your kernel development for KK and LP ROMs!

Thank you. 400MHz will do close to nothing in itself because of thermal throttling, you can try it with Tegrak Overclock. I never touched these settings and I'm afraid to do it. You'll have to wait at least one week for that because I'm taking a break.

As for the color difference, I can explain it for the AOSP variant, it's because a newer s3cfb driver from i9300 is merged in Omni and my kernel is based on that.

 

[BarelyPosting]

Thank you. 400MHz will do close to nothing in itself because of thermal throttling, you can try it with Tegrak Overclock. I never touched these settings and I'm afraid to do it. You'll have to wait at least one week for that because I'm taking a break.

As for the color difference, I can explain it for the AOSP variant, it's because a newer s3cfb driver from i9300 is merged in Omni and my kernel is based on that.

So that's why it was vibrant. Sure sure, I can patiently wait for that 400 mhz release. I'll still try it. Hoho. Thanks again and have a good break.