yashsingh1/xdaforums huggingface dataset:
[Samsung Galaxy Nexus] DevVorteX:
antutu

am I the only one who gets almost constant crashes on the opengl test in antutu? I get like one good test out of 10, usually requiring a reboot to get it to work.

Is there some secret I'm missing?

Also, this dirty kernel is amazing, on v5 now, haven't had time to load up the test or v6, but loving v5. Great job!
[Samsung Galaxy Nexus] AuroEdge:
Concerning his lack of posting his sources and lack of feedback, he probably has shady methods in his kernel
[Samsung Galaxy Nexus] michierusama:
Antutu crashes for me on 3D test lol. Always.
[Samsung Galaxy Nexus] sagara.sandaru:
Maybe bcoz I was on 1080p version
[Samsung Galaxy Nexus] metalspring:
Even with the changed interactive options on mpokang I still get nearly 14k on antutu
[Samsung Galaxy Nexus] metalspring:
Maybe your gnex just needs a fresh start? It's not bad every once in a awhile to go back to stock then reroot and everything to make sure your phone is completely clean
[Samsung Galaxy Nexus] antypas:
Me too. So the governor tuning / faking is b**** in my opinion.

Someone should compare two phone side by side with exactly the same governor settings and same rom.

One phone with Dirty V and on with Mpokang.

Only that way we could make comparisons.
[Samsung Galaxy Nexus] ahmadairfan:
As I remember I flashed DirtyV V5.1/V6 (I forgot) it has 99 while maintaining very smooth performance.

f.K has it at 95 and it is also hell smooth. There's no point giving the go_hispeed_load at 50. :)
[Samsung Galaxy Nexus] antypas:
I tend to disagree with you. Seriously disagree.

When go_hispeed_load is set very high there is a noticeable delay when opening apps (when first touching the screen).

The stock kernel is still snappy enough, even though it is severely outdated, because go_hispeed_load is set at 50.

Only Franco's kernel doesn't have a problem because he divided go_hispeed_load from touchboost and on touch it directly goes to 1036Mhz.
[Samsung Galaxy Nexus] Nephilim:
This is why I have mine set at 78, it's a happy medium that I thoroughly tested and it performs great.

Sent from my Android 4.4 Galaxy Nexus
[Samsung Galaxy Nexus] michierusama:
Finally. That's my score.
[Samsung Galaxy Nexus] Utkarsh-ezzo:
Thank for that info on status bar lag, I will try it soon,

I am not ditching 4.4 at all, I love it, just was doing a general cleaning like metal said some posts above..

And yeah webview is also so smooth.....:p
[Samsung Galaxy Nexus] qtoo941:
I personally found best performance on V5 SuperRam Kernel. There is something wrong with 2.5.14 version - it is lagging on every game and some time outside the games. So in my opinion V5 is the best kernel so far. It doesn't even have wake up lag.
[Samsung Galaxy Nexus] michierusama:
I think so too but is missing some tweak options added in v6
[Samsung Galaxy Nexus] pianistaPL:
On Carbon statusbar is smooth too :)

Sent from Galaxy Nexus powered by CM 11 & Franco r395
[Samsung Galaxy Nexus] Utkarsh-ezzo:
what.....???
[Samsung Galaxy Nexus] osm0sis:
Stock is at 50 because it has a completely different version of interactive, so can't even be brought into the comparison. We owned that version too with the "magic" tunables over on f.K "back in the day". :)

For the newer version 99 is the default go_hispeed_load (because hispeed_freq became the max CPU freq) along with the very important addition of target_loads at 90. When we tuned f.K, we wanted to encourage ramping just a little bit more by dropping that window to 95 and 85, and save battery by dropping the hispeed_freq significantly and letting it ramp beyond it as needed, both of which had the desired effect. 50 IS crazy for the newer interactive, especially when you put target_loads at a HIGHER value, causing it to NEVER reach the target, hence oscillation. ;)

So just to recap since there seems to be some confusion about how the newer interactive works: basically the way interactive works now is it tries to keep the load at target_loads. Below target_loads it ramps down. Above target_loads it will ramp up frequency step by step until target_loads is achieved again, but if the load spikes in a sustained fashion (that's where above_hispeed_delay comes in), then it triggers go_hispeed_load and ramps up to hispeed_freq.

The 99 default is right, the way f.K does it is right, the way mpok did it had it jumping to hispeed and then ramping down, jumping to hispeed and then ramping down, forever, because it could never reach target_loads without hitting go_hispeed_load first.

Check out my Google Doc spreadsheet here: https://groups.google.com/forum/#!topic/francosdevteam/gqDu9ljJ-JA
[Samsung Galaxy Nexus] Nephilim:
Well on both v6 as well as 2/5 having it set to 78 works great for me, a little better on 2/5 I would say but that may be a mixture of how all my settings are working with the newest DirtyV SR.

Sent from my Android 4.4 Galaxy Nexus
[Samsung Galaxy Nexus] thagringo:
yeah, dont know how it is on android but try to build a distro with -O3 set systemwide unconditionally and get ready for runtime breakage.

has someone tried ck bfs on android recently ? It will probably be a pain to backport at this point but maybe worth the effort ?

more crazy stuff : how hard would it be to have F2FS instead of ext4 ?

just dropping ideas.

cheers guys
[Samsung Galaxy Nexus] osm0sis:
Yeah there's nothing wrong with going a bit lower, just remember what you're creating is a window between target_loads and go_hispeed_load that dictates how it ramps, and a margin above go_hispeed_load that increases the likelihood you'll go to hispeed_freq. Making the gap between larger will make it ramp stepwise more, making it smaller will make it more likely to jump to hispeed_freq, and also lowering go_hispeed_load and above_hispeed_delay too much will always make it jump to hispeed_freq. Also putting target_loads lower will cause the device to idle at a higher frequency to sustain the lower load. We kept the gap at about 10% like stock, just increased the margin above go_hispeed_load a little. Always lots of fun to be had with interactive. ;)

It's good to look at the CPU frequency graphs in some apps after using your device for awhile to see if you're getting a decent distribution from your governor tunables. The bar graphs especially helped a lot when I was testing.
[Samsung Galaxy Nexus] bsmitty83:
Android is the same , not everything is -O3 , there are things ROM side that aren't .

As for f2fs , there's a thread on it here

http://xdaforums.com/showthread.php?t=2576085

I bought a note 2 off eBay today , so as soon as I get it I'm gonna try what ive made for using f2fs . (recovery ,ROM , and kernel )
[Samsung Galaxy Nexus] qtoo941:
I got below 10k score with 2.5.14 version .. it pissed me off so i had to flash back V5. Actually V5 SR is the best kernel so far.

cubic ~ 1024 rab, fiops + interactive at 180 ~ 1200 with nephilim's settings (i used to save them before he change values for newest kernel)
[Samsung Galaxy Nexus] bsmitty83:
As for dirtyV , I'm currently working on some things . I'm following mpokangs steps with all the back ported zcache , frontswap , cleancach , and zram and zsmalloc . this is the only logical place your ram performance would be gained . a lot of optimization to the code has taken place from 3.0 to current .

I can't wait till I can keep my nexus plugged into my laptop fulltime . It will allow me to test whenever without worring about needing a phone lol .
[Samsung Galaxy Nexus] Grarak:
those stuff are useless

I already tried them
[Samsung Galaxy Nexus] qtoo941:
this truly made my day :D
[Samsung Galaxy Nexus] n0ve:
I love this thread ...and AK's presence just makes it even better :p.. Anyway sorry I'm jumping back a few pages but regarding commotio and bfq readahead...DHO has his ROM initially set to his ideal tuning ..as we all know rab value perf. Differs per phone...yes there have been studies / threads stating the 'ideal ' bfq read ahead is 512...2048 though for me at least ...performs just as well as far as benchmark scores and I/o access ...it just fluctuates a lot. So to whoever posted about this keep in mind DHO may have ideal perf w this value but you must find what works best for your device. I personally use quadrant pro to test just io at diff tuning to find ideal...take the average of 3 tests. Lastly on a completely different note....CM11 now defaults camera to 1080p so to anyone who uses cm and has issue's flash 1080p version , change setting than flash full bigmem if you'd like.
[Samsung Galaxy Nexus] michierusama:
Lmao mine too.
[Samsung Galaxy Nexus] cujo6801:
Wait what's this thing you speak of..

(Phone?)

Are you referring to the antiquated system of communication..

I mean you actually "talk" to people?

Wow just Wow.....

sent from the DOG pound
[Samsung Galaxy Nexus] pattyboi:):
yes. Pleaseeeee.
[Samsung Galaxy Nexus] Charmacas:
Whatever caused it but my phone rebooted. That was fine because I had Dynamic FSYNC disabled. But then it rebooted again right after it had booted up and bam... Factory reset. F***! Now I have to make a clean installation or restore my NAND backup. :)

Could you please deactivate Dynamic FSYNC by default @ bsmitty83?
[Samsung Galaxy Nexus] metalspring:
If you had it deactivated before then it should stay deactivated until you turn it back on yourself
[Samsung Galaxy Nexus] aosp:
If set at boot in the app if not default kernel setting is used no?
[Samsung Galaxy Nexus] aosp:
[MENTION=4608636]bsmitty83[/MENTION] mpo kernel source on github produce awesome memory benchmarks?
[Samsung Galaxy Nexus] osm0sis:
[MENTION=4608636]bsmitty83[/MENTION] Does your rebase still have timer_slack and boype's unkillable launcher patches? I finally had a moment to look at Vanir's ramdisk and they do include the correct cgroup tweak for boype's timer_slack:

mount cgroup none /dev/cpuctl cpu,timer_slack

Though they forgot to initialize it with the proper sysfs value:

# timer_slack

write /dev/cpuctl/apps/bg_non_interactive/timer_slack.min_slack_ns 100000000

And for the lmk launcher whitelist stuff you'll need to include a smittybootscript.sh or something inserted into /sbin. Let me know what you want to do and I'll be happy to whip it up. :D

It'd be nice to have my init.superuser.rc fixes for native SuperSU support in there too. :good:
[Samsung Galaxy Nexus] bsmitty83:
Not sure . I never made it lol
[Samsung Galaxy Nexus] aosp:
That repo seems to be missing block optimizations too ;)
[Samsung Galaxy Nexus] bsmitty83:
Not at the moment it doesn't . I'm still a ways off , I said performance was gonna take a hit when I updated the op , but its because I reverted 200+ commits , and have only gotten 60 or so back in .
[Samsung Galaxy Nexus] aosp:
You doing a great job dude quality over quantity always win :thumbup:

Bookmark below ;)

http://git.ti.com/

http://git.ti.com/android-sdk
[Samsung Galaxy Nexus] Nephilim:
After manually inserting my settings back into Trickster Mod I can honestly say 2/5 is a beast already. I can't speak for anyone else but with my custom settings it is running amazing! If this is how good it runs off of only 60 commits being re-added I can only imagine what it will be like when the other 140 are returned!!! :D :good:
[Samsung Galaxy Nexus] lilz4life:
LOL no offence man but u say that about every kernal update after u apply ur settings LOL -__-
[Samsung Galaxy Nexus] Nephilim:
You are taking it completely the wrong way. I point that out so that people that just flash the kernel do not complain about not getting the same results as I am getting. Not everyone is using my settings so if I just said that it's working amazing for me then others would sometimes get discouraged because the stock settings are not working well for them due to not knowing I am using different settings.

When I say "using my settings" it is not to brag, it is so that people know that my results come from me using my personal settings and not the stock settings.

BTW, I never said anything about v5 because it really was a step down from v4, so no, I don't say that about every kernel.
[Samsung Galaxy Nexus] lilz4life:
LOL sorry man no harm intended
[Samsung Galaxy Nexus] aosp:
[MENTION=4608636]bsmitty83[/MENTION]

Linaro memset fixes missing

ARM: 7668/1: fix memset-related crashes caused by recent GCC (4.7.2) optimizations

Recent GCC versions (e.g. GCC-4.7.2) perform optimizations based on

assumptions about the implementation of memset and similar functions.

The current ARM optimized memset code does not return the value of

its first argument, as is usually expected from standard implementations.

For instance in the following function:

void debug_mutex_lock_common(struct mutex *lock, struct mutex_waiter *waiter)

{

memset(waiter, MUTEX_DEBUG_INIT, sizeof(*waiter));

waiter->magic = waiter;

INIT_LIST_HEAD(&waiter->list);

}

compiled as:

800554d0 <debug_mutex_lock_common>:

800554d0: e92d4008 push {r3, lr}

800554d4: e1a00001 mov r0, r1

800554d8: e3a02010 mov r2, #16 ; 0x10

800554dc: e3a01011 mov r1, #17 ; 0x11

800554e0: eb04426e bl 80165ea0 <memset>

800554e4: e1a03000 mov r3, r0

800554e8: e583000c str r0, [r3, #12]

800554ec: e5830000 str r0, [r3]

800554f0: e5830004 str r0, [r3, #4]

800554f4: e8bd8008 pop {r3, pc}

GCC assumes memset returns the value of pointer 'waiter' in register r0; causing

register/memory corruptions.

This patch fixes the return value of the assembly version of memset.

It adds a 'mov' instruction and merges an additional load+store into

existing load/store instructions.

For ease of review, here is a breakdown of the patch into 4 simple steps:

Step 1

======

Perform the following substitutions:

ip -> r8, then

r0 -> ip,

and insert 'mov ip, r0' as the first statement of the function.

At this point, we have a memset() implementation returning the proper result,

but corrupting r8 on some paths (the ones that were using ip).

Step 2

======

Make sure r8 is saved and restored when (! CALGN(1)+0) == 1:

save r8:

- str lr, [sp, #-4]!

+ stmfd sp!, {r8, lr}

and restore r8 on both exit paths:

- ldmeqfd sp!, {pc} @ Now <64 bytes to go.

+ ldmeqfd sp!, {r8, pc} @ Now <64 bytes to go.

(...)

tst r2, #16

stmneia ip!, {r1, r3, r8, lr}

- ldr lr, [sp], #4

+ ldmfd sp!, {r8, lr}

Step 3

======

Make sure r8 is saved and restored when (! CALGN(1)+0) == 0:

save r8:

- stmfd sp!, {r4-r7, lr}

+ stmfd sp!, {r4-r8, lr}

and restore r8 on both exit paths:

bgt 3b

- ldmeqfd sp!, {r4-r7, pc}

+ ldmeqfd sp!, {r4-r8, pc}

(...)

tst r2, #16

stmneia ip!, {r4-r7}

- ldmfd sp!, {r4-r7, lr}

+ ldmfd sp!, {r4-r8, lr}

Step 4

======

Rewrite register list "r4-r7, r8" as "r4-r8".

http://goo.gl/jQUi0E

ARM: 7670/1: fix the memset fix

Commit 455bd4c430b0 ("ARM: 7668/1: fix memset-related crashes caused by

recent GCC (4.7.2) optimizations") attempted to fix a compliance issue

with the memset return value. However the memset itself became broken

by that patch for misaligned pointers.

This fixes the above by branching over the entry code from the

misaligned fixup code to avoid reloading the original pointer.

Also, because the function entry alignment is wrong in the Thumb mode

compilation, that fixup code is moved to the end.

While at it, the entry instructions are slightly reworked to help dual

issue pipelines.

http://goo.gl/69e1zu
[Samsung Galaxy Nexus] bsmitty83:
Vanir took care of that one for me this time . but I know about that patch .
[Samsung Galaxy Nexus] Grarak:
you mean this?

https://github.com/Grarak/grakernel-tuna/commit/d745fd7b75d72b1e96e9d6027d9484f2eadf4a9d
[Samsung Galaxy Nexus] aosp:
[MENTION=4443334]Grarak[/MENTION] [MENTION=4608636]bsmitty83[/MENTION] You guys seen this?

ARM: OMAP4: OPP: Enable higher frequency for MPU

With ABB, SmartReflex, and thermal management support in place,

we can now safely enable the higher frequencies on OMAP4 due to

following documents:

- OMAP4430_ES2.x_Public_TRM_vAJ

- OMAP4430_ES2.x_DM_Operating_Condition_Addendum_v0.9

- OMAP4460_ES1.x_Public_TRM_vV

- OMAP4460_ES1.0_ES1.1_DM_Operating_Condition_Addendum_v0.6

- OMAP4470_ES1.0_Public_TRM_vN

- OMAP4470_ES1.0_DM_Operating_Condition_Addendum_v0.6

Since there is an efuse to detect the high performance devices,

we automatically enable that frequency on detection.

http://goo.gl/z09OD7
[Samsung Galaxy Nexus] bsmitty83:
From ages ago ..... Its the beginning of oc after smartreflex was OKed
[Samsung Galaxy Nexus] aosp:
[MENTION=4608636]bsmitty83[/MENTION]

t1: Add support for exFAT file system · e893222 · aidfarh/android_kernel_samsung_t1 · GitHub - http://goo.gl/pDTmbw

[MENTION=4443334]Grarak[/MENTION]

You get to test the gpu drivers I linked you?
[Samsung Galaxy Nexus] aosp:
[MENTION=4608636]bsmitty83[/MENTION]

That exFAT patch depends on this

added j4fs sources · a9a293e · aidfarh/android_kernel_samsung_t1 · GitHub - http://goo.gl/OwsR0Y
[Samsung Galaxy Nexus] michierusama:
When I read he is doing good I feel good about trying so that's the point.

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

I had a reboot using whatsapp lol. And that's was only one today. Don't know why.
[Samsung Galaxy Nexus] bsmitty83:
No . been crazy busy . this weekend hopefully I'll get off dev-host , and have some new build(s) .
[Samsung Galaxy Nexus] Nephilim:
Dude, take your time, 2/5 is running excellent! Can't believe I was so retarded and didn't double check my value inputs after flashing it. :p
[Samsung Galaxy Nexus] bsmitty83:
Pretty soon I'll be on 2 forums lol , I'm on Verizon unlimited so I ebayed a mint note2 . wanted a grey one but settled for this one .

Anyways , yea I'll be taking my time with the build , it usually take's me a few times lol . remember I got zero formal training . but I'm still building . I might put out a test kernel at the end of each night that I build though .

You ever think about putting your tunables in a script ? I was gonna do it but haven't had time .
[Samsung Galaxy Nexus] Nephilim:
That's not a bad idea, something I may ask the script master osm0sis about. ;)

I may be on 2 seperate forums as well in not too long, going to be getting an N5 hopefully in the next few months. Not doing anything with my Gnex though, gonna keep it just for tweaking custom settings to continue sharing here in the Gnex Community. :D
[Samsung Galaxy Nexus] osm0sis:
Haha any time. All the sysfs commands are in the 2nd post of Franco's GN thread and in my old post here:

http://xdaforums.com/showpost.php?p=34977868
[Samsung Galaxy Nexus] juju2011:
It's all good bro I'm in 3 forums because I own 3 phones ATM a mega that has broken digitizer and is used to Google search stuff and toss up between note n gnex although gnex is killing the note in everything on benchmarks thx to your kick ass kernel and nephs kick ass settings
[Samsung Galaxy Nexus] fracama87:
I was thought on n5 too, a couple of friends have it but in the end I've decide to wait next one (maybe is last one) maybe by Motorola-lenovo or moto x2...

Inviato dal mio Galaxy Nexus utilizzando Tapatalk
[Samsung Galaxy Nexus] milojoseph:
Sakuractive

A governor based off of hotplug and ondemand. The phone hotplugs (when it can) when the screen is on, and can be described as a 'hybrid' of hotplug and ondemand

vs.

Interactive (w/nephilim settings)

Interactive scales by default in steps towards max frequency, Ondemand in its default implementation scales immediately to max frequency.

Which did the community choose or would choose.
[Samsung Galaxy Nexus] Nephilim:
My settings aside, I would always go with Interactive because of stability. Our device is well known to not play well with hotplugging, if you are one of the few that can get it to work efficiently that is great news but most of the time you are plagued with issues not limited to, freezing, sod's, random reboots etc.
[Samsung Galaxy Nexus] milojoseph:
Cool.... Im everywhere. Dirty Vr, your thread, your google +. :D Thanks guys.
[Samsung Galaxy Nexus] Nephilim:
Although I created the G+, I more so consider it all of ours at this point, everyone contributes there and it's a really great hub location so that even if we move onto new devices we can always share our experience and knowledge among each other in one place. :)
[Samsung Galaxy Nexus] ak:
Toolchain:

http://xdaforums.com/showpost.php?p=50107146&postcount=344
[Samsung Galaxy Nexus] ak:
you and others guys are fantastic! :cowboy:
[Samsung Galaxy Nexus] Vekhez:
Don't forget that guy @ak
[Samsung Galaxy Nexus] metalspring:
well, thats definitely a different setup than usual lol

normally its just "export ARCH=arm", "export CROSS_COMPILE=<path of toolchain>/bin/arm-eabi-"

this one you actually have to do "export ARCH=arm", "export CROSS_COMPILE=<path of toolchain>/bin/arm-cortex_a9-linux-gnueabihf-"

I'll have to see how it goes along with other suggested changes (like more graphite and lto cflags, and trying out -Ofast instead of -O3"
[Samsung Galaxy Nexus] ak:
You have to change only the dir the toolchain have an alias by default:

- Possibility to use the alias arm-gnueabi- as prefix of each tool
[Samsung Galaxy Nexus] metalspring:
Either way should work though, right? It compiled anyway lol

Btw, first impressions on using the normal linaro 4.7 toolchain but changing -O3 to -Ofast, adding -fno-fat-lto-objects to the LTO cflags, -floop-parallelize-all, and -fgraphite-identity to the graphite cflags doesnt seem to cause any issues and it actually might be a little bit faster as well

For dirtyv v6-

CPU max 1500, min 350 FIOPS, read ahead buffer 1024, dyn fsync on, GPU 384, temp limit 80
[Samsung Galaxy Nexus] garyngkt:
So far 2.5.14 has been good for me, no wake up lags on interactive. :good:
[Samsung Galaxy Nexus] ak:
Very good info.?

AK&4&7
[Samsung Galaxy Nexus] nasty007:
same here, interactive is running great, no wake up lag

Sent from my Galaxy Nexus
[Samsung Galaxy Nexus] n0ve:
Edit : guess it doesn't matter
[Samsung Galaxy Nexus] Grarak:
Nice to see a galaxy mega user here!

Currently I am on 4 forums and maintain 3 kernels. That's already a 24/7 job
[Samsung Galaxy Nexus] metalspring:
Btw, [MENTION=4608636]bsmitty83[/MENTION], is your github up to date? I thought you said you had the memset fixes included now? I dont see any commits for them though

All the same commits were in your old builds as well, plus if those memset fixes were applied, then it *should* work just fine with linaro 4.8 according to linaro here and here

The commits needed are here- http://android.git.linaro.org/gitwe...it;h=7e64a7e90b863c3cf8261ff8f0174a33cf314956

and here http://android.git.linaro.org/gitwe...it;h=3bcca981220312457a0fd06bcaa2774789ec61a5

I'd try to add them myself but they dont merge well and I dont know C to fix them lol

Also, using the toolchain [MENTION=3685904]ak[/MENTION] posted seems to improve performance and boot time, along with changing all -O3 to -Ofast, adding -fgraphite-identity -floop-parallelize-all to the graphite cflags and -fno-fat-lto-objects to LTO cflags
[Samsung Galaxy Nexus] bsmitty83:
[MENTION=4328678]metalspring[/MENTION] , I'd have to look but its a pretty old patchset . I'd be surprised if vanir didn't add that . at any rate I've had them in kernels before and still had issues with 4.8gcc
[Samsung Galaxy Nexus] Grarak:
I cannot see them in your source

https://github.com/bsmitty83/DirtyV_tuna/commits/SmittyV/arch/arm/lib/memset.S

They are not that old, also they aren't from omap
[Samsung Galaxy Nexus] metalspring:
exactly what I thought, however, I have no idea if the patches by Boy Petersen would interfere or not, I just reverted those 3 patches to cherry-pick the linaro memset fixes

going to do a quick compile with linaro 4.8 to see if it works and performs any better or worse
[Samsung Galaxy Nexus] bsmitty83:
No your right , they are not there . ill add them when i get home

I looked at the diff and it seems pretty straightforward . I'll find the commit I was thinking of
[Samsung Galaxy Nexus] thagringo:
thanks, missed that thread.

cheers
[Samsung Galaxy Nexus] bsmitty83:
I was using that patch when I was building with the 4.8 toolchain but when everyone was getting lockups I reverted it
[Samsung Galaxy Nexus] spirit1002:
The wake up issue of interactive is gone,but still little small problem of interactive.

The value of target_loads couldn't be changed,the value is always "0".(SR-2.5.14)