yashsingh1/xdaforums huggingface dataset:
[Captivate Android Development] rajendra82:
Until that happens though (and even afterwards), I would love for these juwe11 modified LMK settings to be the default. I was going to hold off until 24 hour uptime was achieved before posting this, but I think I have put the new LMK settings through their paces. They work much better than the default preset while running 0.4.4.9. My phone typically has 270 MB/340 MB memory used up when first booted. Under the original LMK settings the memory usage would creep upwards over time and in about 4-8 hours, the phone would use up 320 MB. At this point it would start lag and/or freeze up altogether. This seemed to happen whether ZRAM was enabled or not. Going into task manager, and trying to clear memory would do absolutely nothing, and only a reboot would bring the phone back to usable speed. With these new settings I am seeing memory usage staying below 280 MB, with an occasional creep up to 285 MB after a prolonged period of heavy usage. After leaving idle for a while, the memory gets cleared up automatically. I am currently at almost 20 hours up time, gone through overnight charging, standby in pocket, and my typical usage of browsing the web and xda forums, installed and uninstalled apps, and used memory is dropped back down to 265 MB. I have not needed to hit clear memory once after the new settings went into effect. This is the first time I have seen the phone behave this well under Gingerbread. At this rate I could go a week without rebooting (unless a new version of Talon is flashed).
[Captivate Android Development] demarton:
curious about your result, give it time, I usually tested it for 48 hours to get the absolute worst ram situation. Many hacks/script didn't show it's flaw only on 24 hours.
[Captivate Android Development] rajendra82:
I am not going to reboot unless I have to, so I will give it as much time as I can. But nearly 24 hours is already a huge improvements over the default preset. Since I see basically a flat memory footprint over time, I can extrapolate and say that this should make it to 48 hours and beyond easily.
[Captivate Android Development] existz:
Well, we got a couple new fixes added that should help with current setup...next test will have the same lmk settings, but a fix for some regression that was introduced with the new lowmemkill driver updates...as well as a patch from ck patchset to drop swap cache aggressively ... I want to see how these do before changing actual lmk settings. Also, with the 1.2ghz version, I removed the 1ghz step, that way it keeps the number of frequencies the same as stock (there's quite a few settings in the source that are setup based on stock frequency layout.. like setting L2 for example... with stock layout that would be 400mhz, with extra step added that would be 800mhz...so it could possibly stabilize things, and help battery some..since its running a step lower)..(and no, its not the same as just disabling 1ghz with VC or whatever, it does not effect actual Lx settings)..plus when using 1.2ghz, 1ghz sstep is rarely used..so removing an extra step should help scaling some and make things smoother. Plus using a new toolchain, Linaro for Android GCC 4.6.2.. quite a bit of changes since last test...alot of testers are reporting great results with latest private test (0.4.4.12).. so next one should be even better. But it seems the charge bug is still there, thought we had it fixed, then merged in latest Samsung source and all changed..so back to the drawing board...ill try and get 0.4.4.13 as a public test, need to see how a few more things go before posting a new one
[Captivate Android Development] -Thrive-:
I am curious because I have never experienced the behavior and lag you are describing and I have always used the default LMK settings. Also I tried turning ZRAM off and could see no discernible difference. Is this the difference between running Talon on Continuum vs Apex? Makes it difficult for the devs to decide on defaults when results from the different platforms vary so much.
[Captivate Android Development] rajendra82:
I think it has less to do with the ROM base, and more to do with how many services and widgets you have running in the background. I bought my phone to enjoy and use, so I have five home screens and widgets for checking weather, news, twitter feeds, daily schedule and such on each one. I also don't like to turn off my phone at night, as I would like to be able to unlock it and play with it when I get up. If you are not pushing your phone like I am, you are likely going to not run into the situation, where the memory is all used up and the phone is struggling to keep up.
[Captivate Android Development] -Thrive-:
I hear you but I am running 5 different widgets and often run either Cardio Trainer or Navigon and PlayerPro simultaneously with no performance or memory issues and these GPS apps really use a lot of resources. I don't leave my phone on overnight so I'm sure that makes a difference but I think there may be something else at play here. Maybe misbehaving apps or services that don't release memory or refuse to be killed.
[Captivate Android Development] rajendra82:
Not leaving the phone overnight is the key. The lag does not hit me until several hours after booting. Under Froyo I never knew how long the phone had been running. Under Gingerbread, I could tell until the new LMK settings were applied. Try charging it while on tonight with the old preset and ZRAM enabled, and you will see this behavior tomorrow morning.
[Captivate Android Development] existz:
0.4.4.13 Public Test

Included in this test is both 1ghz and 1.2ghz versions, but only non-bigmem..this is only for the test

In the 1.2ghz version, the 1ghz step was removed. So the steps are as followed

100-200-400-800-1000 <--1ghz version

100-200-400-800-1200 <--1.2ghz version

NOTE: With 1200 versions you might have to toggle max clock after first time booting, just toggle to 800 and back to 1200 and save settings..

Where safe boot is set to 1ghz, its sticking at 800 because 1ghz was removed, just toggle it once, then save settings and it will be fine after that

Make sure to wipe Voltage settings!

Full 0.4.4 Changelog

new tweaked LMK settings

updated to 2.6.35.13 base

updated latest samsung source

added new kernel boot logo

disable more kernel debug

updated to JVR version/modules

set VFP mfpu=neon optimization

set usb charging lock to 100mhz

backport cpufreq from 2.6.36.1

rfkill updates from Samsung Infuse

wifi driver updates from Samsung Infuse

upstream fixes for lowmemkill driver

upstream fixes for sched_autogroup

upstream fixes for RCU/TinyRCU

fix corruption issue with ZRAM

compiled with Linaro Android GCC 4.6.2

switch to TinyRCU (smaller memory footprint)

more random upstream fixes to ARM/SAMSUNG

added sampling down factor to ondemand

XZ kernel compression; initramfs to none

tons of general fixes from zacharias.maladroit

drop voltage for RAM(1.8->1.6) and ADC(3.3->3.0)

Changes since 0.4.4.9

new tweaked lowmemorykiller settings

fully updated to 2.6.35.13 + various fixes

picked various commits from 2.6.35.14+

merged backport of CPUFREQ from 2.6.36.1

compiled with Linaro Android 4.6.2 toolchains

battery/power patch from Samsung Infuse source

merged in latest changes from samsung opensource

removed 1ghz step in 1.2ghz version (more stable)

CK patchset: mm-drop_swap_cache_aggressively

re-add #define SEC_ADJUST_LMK in lmk driver

drop voltage for RAM(1.8->1.6) and ADC(3.3->3.0)

Improve latencies under load by decreasing minimum scheduling granularity

NOTE

There are some new LMK settings in the build, with other various lowmemorykiller fixes, so please report on how these settings work for you
[Captivate Android Development] jontoo:
Thanks mate, will try it now :)
[Captivate Android Development] Sqb:
Thank you sir. Will flash once one hundred.

Sent from a rock on fire in the middle of the sea
[Captivate Android Development] magistrateee:
Do I still need to disable the ZRAM in this version?
[Captivate Android Development] existz:
Well, changes have been made with ZRAM enabled..so try it with it enabled, if it doesnt seem to work well for you, you can always disable it..but most of the fixes were to improve performance with it enabled
[Captivate Android Development] Thunder22:
Using talon 0.4.4.13, I just checked in cpu spy and it says that 1200 mhz is not being used at all. Only running 800mhz and below. Voltage settings have also been cleared in cwm.
[Captivate Android Development] -Thrive-:
Erased

10 char
[Captivate Android Development] tmng95014:
You would need to wipe voltage in recovery then after reboot, go to Voltage Control, you will need to push slider to 800MHz and then 1200MHz. Save setting and you should be set.
[Captivate Android Development] Rrryan2:
My phone was almost unusable on 0.4.4.9 until ZRAM was disabled and them improved even more with the Juwe LMK settings, but running great so far on .13 with no changes at all.. All CPU states in use, nice and stable and smooth.

Nice job once again!
[Captivate Android Development] existz:
Just toggle max clock in Voltage Control, just slide to 800 and back to 1200, i believe its from where its set to safe boot at 1ghz, and now theres no 1ghz its getting stuck at 800..but just toggle it back and forth and save settings and alls good...ill fix this in next build
[Captivate Android Development] Sqb:
Great work. This test just as fast as last but with zram. I see the true monster talon is showing. Thank you for the countless hours

Sent from a rock on fire in the middle of the sea
[Captivate Android Development] kodos96:
If you're going to keep posting these settings on the thread, please include the following disclaimer, in bold:

These settings will effectively disable multitasking on your phone. They may make things feel a bit faster, but will limit you to running only a couple apps at a time. Do not use these settings unless that's what you're looking for.

EDIT: I realized after posting that my original wording was a bit of an exaggeration.
[Captivate Android Development] Rrryan2:
Yikes. In his defense though, disabling zram on 0.4.4.9 was the only thing that got my phone to a usable state. The rest of the lmk tweaks did indeed improve the seat-of-pants feel & snappiness, and I didn't notice any decline in multitasking abilitiy, able to switch back and forth between browser and apps without any feeling dead.

That said, while on .9 my phone was barely usable with stock settings with the stock .13 settings (including leaving zram enabled) I'm doing just fine and the Juwe settings have proved at a minimum unnecessary so far.
[Captivate Android Development] kodos96:
Yeah, .9 was not that great a release, memory-management-wise... last week I was pretty busy at work and not following the test releases too closely - we let a bug creep into the lmk kernel driver in the course of merging some patches, and I didn't notice it for a couple days. But that's fixed now in .13, and now that those new patches are actually working, memory management should be MUCH improved... not just over .9, but over all previous releases. So give it a try with the stock settings and see how it goes.

BTW, your name sounds familiar... were you the guy from the gps fix threads back on froyo?
[Captivate Android Development] kodos96:
So it sounds like what you're describing is the effect of the memory leak.... and unfortunately, no LMK settings, no matter how aggressive, are going to solve that: if killing your apps manually with "clear memory" isn't freeing up any ram, then killing them automatically with LMK isn't going to either.

The memory leak MIGHT be fixed/improved in .13 - it remains to be seen... but if it turns out it is still there, then more aggressive LMK won't help.

On the upside, with the new changes in .13, you're going to see a bit more ram to start out with, thanks to more ZRAM usage... so even if it turns out we're still leaking memory, it shouldn't hurt quite as bad since you have a but more to work with.
[Captivate Android Development] Rrryan2:
As previously reported, stock .13 memory settings seem to work just great on Apex 9.0

Yeah, that would be me. For a while I got sick of gps and some of the goofier aspects of XDA user support, and as Samsung GB GPS implementation was a lot less terrible than under Eclair/Froyo I'd mostly abandoned my earlier efforts.

A few things have come to light recently though and I'm in the initial stages of working with another member on a package of GB-specific GPS tweaks. Stay tuned etc.

I've observed little to no leak so far on .13, but for various reasons I haven't gone more than a few hours without rebooting since installing either. But while .9 started giving me crap right away and was just asking to be slapped around, .13 has been much more easygoing from the get-go and hasn't made me want to think about messing with it. ;)
[Captivate Android Development] kodos96:
No, it isn't the rom that makes the difference, it's the user. It comes down to personal preference - how you use your phone, and what you care about. Personally, I use my phone primarily for web browsing, and when your browser gets killed, forcing it to have to reload and re-render all your tabs when you switch back to it... well that really really sucks. So for me, multitasking ability, i.e. the ability to switch away from your apps without them getting killed while they're in the background, is my main concern. I realize though that not everyone uses their phone the same way I do, so when setting Talon's defaults, I try to choose settings that are a balanced medium between the extreme multitasking settings that I use myself, and the extreme single-tasking settings that people have been discussing here.
[Captivate Android Development] demarton:
I'm on the same boat, nothing more annoying than multiple tab opened, sms came in, read it, back to browser only to found all tabs reloading :mad:.

Froyo multitask/ram situation works much better so far IMHO.
[Captivate Android Development] upNsmokeAllDay:
Does the ram.conf get edited when we flash the kernel or do we have to manually edit it?
[Captivate Android Development] pikachu01:
You don't have to edit the ram.conf unless you want to change the stock LMK settings. In version 0.4.4.13, the stock LMK settings are pretty robust and snappy.
[Captivate Android Development] Jep56:
Flashed .13 last night. Pulled cord at 100%, after 4 hours and had a drop to 98%, pulled it this morning...97%. Had drops to the 70's with .9, plus have had no lag as of yet.
[Captivate Android Development] rajendra82:
I was aware of the memory leak issue, and the behavior I saw with stock LMK and 0.4.4.9 was consistent with having one. The aggressive LMK did seem to stop the adverse effects of that leak. After 24 hours I had the same amount of RAM free as when I booted up. So if there was still a leak, the aggressive LMK was probably squashing it by preventing the leaky process from running for a long period of time. Under the default settings, the clear memory button sometimes could not free enough RAM for me when the usage had grown into the 300+ MB range, and there was UI lag. In those instances, no matter how many times I pressed that button, and no matter how many apps the system said it had killed, the used up footprint barely shrank. Those aggressive LMK setting however never seemed to allow usage to grow into that lag inducing range over the 24 hour period I used them.

I usually use my phone to rapidly switch around between various apps to check on weather, twitter feeds, xda postings, and news, and play an occasional session of a game. With my type of usage, I like my phone to be ready to go when I unlock it (i.e., have enough memory free to scroll around on the home screens and app drawer lag free and be ready to launch a new app), and have the launcher never be killed in the background, so that when I close out of an app to open another, there is no annoying redraw. I rarely open more than one tab on the browser, and rarely stay in any single app for a long period of time, so the aggressive killing behavior of those modified LMK settings did not bother me too much, because they left the launcher alone, and I always had memory to spare to run any app when I asked.

That being said, the code tweaks in release 0.4.4.13 and the associated default LMK settings seem to be doing a much better job of matching my needs so far than 0.4.4.9 did. Memory usage appears to be much more stable over time, and hasn't crept into the lag inducing territory. I haven't put the phone fully through its paces today, but so far so good. Keep up the great work.
[Captivate Android Development] melvinaury:
I install the version 4.4.13 and today I experience the charge bug. After disconnect the phone the battery goes down to 90%.

The new kernel is working great.

Good Job.
[Captivate Android Development] Wdustin1:
I have had the charger bug on .9 for the past 3 days I installed

.13 last night and this morning I woke up unplugged and it dropped to 98% very good work, this kernel seems like a good one now
[Captivate Android Development] hobbs:
Working great. woke up to 99% battery this morning.
[Captivate Android Development] eliminat:
So under the previous kernels Pocket Legends had been completely refusing to update. updated to .13 and it updated without a single problem. don't know the how/why of it, but I like less annoyances.
[Captivate Android Development] rajendra82:
When apps refuse to update, the solution is to clear the cache for the Market application. When you installed the new kernel yesterday, the script wiped the cache partition. That's what did the trick.
[Captivate Android Development] eliminat:
Trust me, I've done this. I've wiped ALL caches, (market, dalvik, individual app, etc) and it still wouldn't update. This has happened to me before, and usually had to go download the apk and manually install it for it to take. I think it may partly be because it's a 28 MB apk. When I updated from .8 to .9 it also wiped the caches with the script, still wouldn't update. With .13 it did it first time, no problem.
[Captivate Android Development] manny05:
Latest kernel is running smoothly so far. Charging bug seems to be fix. Although it's only been a couple of hours lol but no problems have yet to come up

Captivate running dlev's latest rom

Talon kernel/snail

Overclocked and undervolt
[Captivate Android Development] topiratiko:
With ALL due respect, Kodos96,

The reason ive explored other ram hack type stuff was because the original lmk/memory settings were less than stellar. Rendered my phone nearly unusable and i wasnt the only one. I posted my findings on this forum to try to help people like myself...those who didnt want to press an app icon and watch the icon backround light up for 2 seconds and then load the app...Now i understand that juwes11's settings arent the greatest in terms of multitasking....the new stock settings are much improved...but in my opinion NOT as smooth as 4.4.12 with juwe 11's settings. So i took it upon myself to come up with my OWN. These settings, at least for me, maintain multitasking ability (no browser reloads etc) for MY useage style. Yourself and anyone interested are free to put these settings through the paces as they are a perfect medium for me. The beauty of Android after all is customization to fit individual users needs. My intent is not to step on toes but to explore options. Anyone who tries this please leave feedback. This whole memory thing is a HUGE issue on gb which is why this whole "situation" even exists.

Sent from my Apex Blue JVR Samsung Captivate.
[Captivate Android Development] demarton:
we need more RAM..

I wish smartphone are like PC,

new OS launch, require more RAM, go out, buy more ram then plugged it in, so simple.. sigh..
[Captivate Android Development] LNJ:
So why isn't bigmem the default release considering the biggest problem we have is ram consumption?

How many of us actually use 720p video recording on these crappy camera sensor anyway?
[Captivate Android Development] topiratiko:
If you dont need 720 then by all means use bigmem....i have 2 kids 3 and 18 mths and record them doing dumb **** all the time lol...vids look GOOD!

Sent from my Apex Blue JVR Samsung Captivate.
[Captivate Android Development] kodos96:
If there's been a change to the default ram.conf since the last kernel version, then it updates it automatically when you flash. If not, then it leaves your existing ram.conf in place.
[Captivate Android Development] kodos96:
Right, I understand all that... which is why I'm not telling you to not post your settings - I'm just telling you that if you're going to post them, make sure you make clear in your post that these are settings geared towards people who don't care too much about multitasking, and just want their phone to be as lag-free as possible, even if that means killing your apps early.

Everyone uses their phone differently, and for some usage styles, these settings may be great.... I just don't want new users showing up, reading the last few pages of the thread, and just using these settings cause they were recommended as "faster", without realizing that they're making a tradeoff between speed and multitasking.
[Captivate Android Development] tmng95014:
+1 and the other problem if there is issue then who is going to fix it. I think disclaimer is necessary.
[Captivate Android Development] kodos96:
I agree. But I can see the other side of the argument too - since the camera app still has 720p as a selectable option, but it doesn't work, it may appear "broken" to users who aren't expecting it... so I can understand the desire to not have anything visibly broken on the default kernel.

What I wish would happen is for rom authors to remove the 720p option from the camera app, and install the bigmem kernel by default, and then offer an optional cwm flashable package which installs the 720p enabled camera app and kernel. That'd be cool.
[Captivate Android Development] RTBee:
+1 I don't do a lot of video with my phone, let's face it, it is a PHONE, but when I do, I want it to look good and 720p looks good!
[Captivate Android Development] RTBee:
Let's see, More memory tends to 'break' a memory hogging app like video. What's wrong with this 'picture' :rolleyes:
[Captivate Android Development] rajendra82:
I don't think the issue is necessarily Gingerbread. I think either Samsung underestimated the RAM that should have been included in Galaxy S, leaving us with little free memory after booting up, or screwed up their Gingerbread source by adding some bugs that caused a crunch over time. My Wife's Nook Color and New HTC status both run Gingerbread (one on CM7 and the other on Sense 2.1 for Messenger). Neither device shows the buildup of lag over time behavior I have seen in the beta GB ROMs on the Captivate. I can never tell by looking at the behavior of these other devices if they were last booted up a minute ago or last week.
[Captivate Android Development] smokestack76:
So far so good for me. No more charge bug. Not 100% but 99 is good enough for me. Everything works good and phone is fast. I have been testing and always use these kernels. So i like the new test version :D
[Captivate Android Development] existz:
0.4.4.14 Public Test

0.4.4.14

Changes since 0.4.4.13

- some more mm/vmscan/sched upstream fixes

- reverted backport of CPUFREQ from 2.6.36

- reverted back to CodeSourcery 2009q3 toolchains

- remove 1ghz safe boot for 1.2ghz version (theres no 1ghz)

Reverted back to CS 2009q3 toolchains to see if Linaro was the cause for some of the issues. Let me know if it fixes Wifi/BT issue.

Also removed the 1ghz safe boot since theres no 1ghz for 1.2ghz version. This should fix it sticking at 800mhz sometimes.
[Captivate Android Development] topiratiko:
I felt that the initial Linaro release introduced a new level of smoothness..im gonna stay on 4.4.13 for a while..whats this bluetooth issue so i can look out for it?