Related
http://www.pcworld.com/businesscent...x_kernel_patch_delivers_huge_speed_boost.html
http://forum.xda-developers.com/showthread.php?t=844458
could this be worked into Epic 4G kernels as well?
tyl3rdurden said:
http://www.pcworld.com/businesscent...x_kernel_patch_delivers_huge_speed_boost.html
http://forum.xda-developers.com/showthread.php?t=844458
could this be worked into Epic 4G kernels as well?
Click to expand...
Click to collapse
WOW. I am seriously impressed by your "keeping up with the times" mentality. Good job on noticing this!
So...
"n tests by Galbraith, the patch reportedly produced a drop in the maximum latency of more than 10 times and in the average latency of the desktop by about 60 times. Though the merge window is now closed for the Linux 2.6.37 kernel, the new patch should make it into version 2.6.38."
Along with an Overclocked Froyo kernel (once source is out) this should REALLY improve our experiences.
I mentioned in another thread that I am in talks with Paragon software
http://www.paragon-software.com/exp...ocs/technologies/Paragon_UFSD_for_Android.pdf
for NTFS and HSF access. I think that is is POSSIBLE that this is actually a software patch, although it may need to be placed into the kernel itself as a driver. I promise to update as soon as they get back to me as I just spoke to the devs there yesterday.
Looks like our experience is about to improve dramatically!
Already in IntersectRavens latest kernel and wildmonk's latest beta kernels for nexus one. Check the threads
Click to expand...
Click to collapse
From the other xda thread someone mentioned that some kernels have already implemented. I am sure some of them would be glad to share how it is implemented and how easily it can be done. I know it is different phones/kernels but the idea behind it should be similar.
Dulanic said:
From the other xda thread someone mentioned that some kernels have already implemented. I am sure some of them would be glad to share how it is implemented and how easily it can be done. I know it is different phones/kernels but the idea behind it should be similar.
Click to expand...
Click to collapse
We don't have a source kernel for Froyo yet to do this. Someone correct me if I am wrong please.
Edit: I can't find anything mentioning this patch. If anyone has a link post it. I don't believe this is implemented anywhere yet.
I found the below info here:
http://www.reseize.com/2010/11/linux-kernel-patch-that-does-wonders.html
Below is the video of the Linux desktop when running the kernel and the patch in question was applied but but disabled:
As you can see, the experience when compiling the Linux kernel with so many jobs is rather troubling to the Linux desktop experience. At no point in the video was the 1080p sample video paused, but that was just where the current mainline Linux kernel is at with 2.6.37. There was also some stuttering with glxgears and some responsiveness elsewhere. This is even with all of the Linux 2.6.37 kernel improvements up to today. If recording a video of an older kernel release, the experience is even more horrific! Now let's see what happens when enabling the patch's new scheduler code
It is truly a night and day difference. The 1080p Ogg video now played smoothly a majority of the time when still compiling the Linux kernel with 64 jobs. Glxgears was also better and the window movements and desktop interactivity was far better. When compiling the Linux kernel with 128 jobs or other workloads that apply even greater strain, the results are even more dramatic, but it is not great for a video demonstration; the first video recorded under greater strained made the "before look" appear as like a still photograph.
This could be potentially patched into our Eclair kernel if the changes aren't too intrusive, and by the sounds of it they're not.
The mainline patch was against 2.6.39 kernel however, our froyo kernel will be 2.6.32 and eclair is 2.6.29 - so we're several revisions behind in eclair.
It's definitely interesting, but it's geared toward desktops using the group scheduler - absolutely worth a try if that scheduler works with android easily ( most of the community kernels are using BFS scheduler however )
cicada said:
This could be potentially patched into our Eclair kernel if the changes aren't too intrusive, and by the sounds of it they're not.
The mainline patch was against 2.6.39 kernel however, our froyo kernel will be 2.6.32 and eclair is 2.6.29 - so we're several revisions behind in eclair.
It's definitely interesting, but it's geared toward desktops using the group scheduler - absolutely worth a try if that scheduler works with android easily ( most of the community kernels are using BFS scheduler however )
Click to expand...
Click to collapse
Sniff...
It did sound a little too good to be true. Well, eventually we will get 2.6.38 and that has it built in, if the desktop group scheduler can even be used at all it seems.
but because its in other peoples' kernels cant it be easily ported into ours?
tyl3rdurden said:
but because its in other peoples' kernels cant it be easily ported into ours?
Click to expand...
Click to collapse
It's very possible to patch in. If it's been done before, anyway.
But, because it is based on the .39 kernel, it might be a little buggy. Or a lot buggy. You wanna link me to a kernel that has it and I'll look into it? I probably will wait for Froyo source for at least the .32 kernel.
Here's what Linus himself had to say about the patch:
Yeah. And I have to say that I'm (very happily) surprised by just how small that patch really ends up being, and how it's not intrusive or ugly either.
I'm also very happy with just what it does to interactive performance. Admittedly, my "testcase" is really trivial (reading email in a web-browser, scrolling around a bit, while doing a "make -j64" on the kernel at the same time), but it's a test-case that is very relevant for me. And it is a _huge_ improvement.
It's an improvement for things like smooth scrolling around, but what I found more interesting was how it seems to really make web pages load a lot faster. Maybe it shouldn't have been surprising, but I always associated that with network performance. But there's clearly enough of a CPU load when loading a new web page that if you have a load average of 50+ at the same time, you _will_ be starved for CPU in the loading process, and probably won't get all the http requests out quickly enough.
So I think this is firmly one of those "real improvement" patches. Good job. Group scheduling goes from "useful for some specific server loads" to "that's a killer feature".
Click to expand...
Click to collapse
DevinXtreme said:
It's very possible to patch in. If it's been done before, anyway.
But, because it is based on the .39 kernel, it might be a little buggy. Or a lot buggy. You wanna link me to a kernel that has it and I'll look into it? I probably will wait for Froyo source for at least the .32 kernel.
Click to expand...
Click to collapse
Devin- I agree with waiting until the Froyo source is out for attempting to implement this. I'm not sure that group scheduling is even an option in the Android kernel. But I don't think anyone has done this so I doubt any links are coming your way.
Edit: Found this here- http://groups.google.com/group/android-kernel/browse_thread/thread/f47d9d4f4e6a116a/ab1a8ab42bb0b84a
Android is using the CFS.
They are combine with RT scheduling.
When you playing the audio and video service, paltform change the
scheduling policy and change the schedule prority.
search the platform code
dalvik has policy n proiorty setting code, also framework related with
audio n video
check the init.rc and cutil folder
u need to search the platform after eclair release (Froyo)
cicada said:
( most of the community kernels are using BFS scheduler however )
Click to expand...
Click to collapse
Actually, no Epic kernel uses BFS. It isn't stable on our hardware, and its not worth porting. Android uses CFS by default, and then the CFQ scheduler I think, but most have switched from CFS/CFQ to CFS/BFQ combination. I know mine & Devin's kernels have.
Geniusdog254 said:
Actually, no Epic kernel uses BFS. It isn't stable on our hardware, and its not worth porting. Android uses CFS by default, and then the CFQ scheduler I think, but most have switched from CFS/CFQ to CFS/BFQ combination. I know mine & Devin's kernels have.
Click to expand...
Click to collapse
Ok then, so in your professional opinion is this patch a possibility still?
Enter your search termsSubmit search formWeblkml.org
Subject [RFC/RFT PATCH] sched: automated per tty task groups
From Mike Galbraith <>
Date Tue, 19 Oct 2010 11:16:04 +0200
Greetings,
Comments, suggestions etc highly welcome.
This patch implements an idea from Linus, to automatically create task groups
per tty, to improve desktop interactivity under hefty load such as kbuild. The
feature is enabled from boot by default, The default setting can be changed via
the boot option ttysched=0, and can be can be turned on or off on the fly via
echo [01] > /proc/sys/kernel/sched_tty_sched_enabled.
Link to code: http://forums.opensuse.org/english/...ernel-speed-up-patch-file-mike-galbraith.html
Thanks for the clarification Geniusdog254.
ZenInsight, any chance you can prune down that post and just use a link? The patch is all over the web right now, and it's hard to scroll by on a phone
ZenInsight said:
Ok then, so in your professional opinion is this patch a possibility still?
Click to expand...
Click to collapse
I'm sure its possible, I just haven't looked at it yet. Like I stated before, until we get 2.6.32 FroYo kernel source I'm not doing any devving besides app work (maybe)
EDIT: Devin said on the last page that he'll look into it. I know IntersectRavens Nexus kernel has it, but I haven't looked into any reports of how much it helps.
Also found this:
Phoronix recently published an article regarding a ~200 lines Linux Kernel patch that improves responsiveness under system strain. Well, Lennart Poettering, a RedHat developer replied to Linus Torvalds on a maling list with an alternative to this patch that does the same thing yet all you have to do is run 2 commands and paste 4 lines in your ~/.bashrc file. I know it sounds unbelievable, but apparently someone even ran some tests which prove that Lennart's solution works. Read on!
Lennart explains you have to add this to your ~/.bashrc file (important: this won't work on Ubuntu. See instructions for Ubuntu further down the post!):
CODE:
if [ "$PS1" ] ; then
mkdir -m 0700 /sys/fs/cgroup/cpu/user/$$
echo $$ > /sys/fs/cgroup/cpu/user/$$/tasks
fi
Linux terminal:
mount -t cgroup cgroup /sys/fs/cgroup/cpu -o cpu
mkdir -m 0777 /sys/fs/cgroup/cpu/user
Further more, a reply to Lennart's email states that his approach is actually better then the actual Kernel patch:
I've done some tests and the result is that Lennart's approach seems to work best. It also _feels_ better interactively compared to the vanilla kernel and in-kernel cgrougs on my machine. Also it's really nice to have an interface to actually see what is going on. With the kernel patch you're totally in the dark about what is going on right now.
-Markus Trippelsdorf
The reply also includes some benchmarks you can see @ http://lkml.org/lkml/2010/11/16/392
Found all this here (Ubuntu patch info too):
http://www.webupd8.org/2010/11/alternative-to-200-lines-kernel-patch.html
I've always been curious about other file systems rather than rfs on OneNAND devices and their performances.
For example, supercurio, a famous developer of voodoo lagfix/color/sound, formatted /dbdata on i9000 Galaxy S (which is also OneNAND) and reports better performance, although I can't find any evidence.
Since rfs is basically FAT with POSIX and some other stuffs, other "advanced" file systems will do better performances-- this is what I thought. Yes there is no lag that occurs on other Galaxy S on Epic 4G, and it's because our OneNAND is physically superfast NAND flash with SLC NAND, NOR logic and SRAM buffer. Much faster than moviNAND(of Galaxy S) or other NAND flash. That's all. That doesn't mean changing file system from rfs to another will do nothing. With rfs the performance is good enough already. The question is does other file systems increase the performance.
(and Yes quadrant is a terrible benchmark software. It does not give any criterion about its benchmark, and boosts too much points on I/O.)
Deceived by Quantum Rom's quadrant tmpfs trick, I decided to install VIPERrom's ext2 "lagfix" (although I don't want to call it "lag fix" because there is no lag on our Epic 4G) and run RL benchmark of SQLite performance. Since SQLite is sometimes quite relevant to real usage in our Android life, especially for database-using applications, please don't call it mere benchmark. Anyway, the result gives:
In order of
1000 INSERTs /
25000 INSERTs in a transaction /
25000 INSERTs into an indexed table in a transaction /
100 SELECTs without an index /
100 SELECTs on a string comparison /
Creating an index /
5000 SELECTs with an index /
1000 UPDATEs without an index /
25000 UPDATEs with an index /
INSERTs from a SELECT /
DELETE without an index /
DELETE with an index /
DROP TABLE /
Overall
Normal, rfs, DK05 FroYo:
11.738 / 2.91 / 2.903 / 0.096 / 0.076 / 1.095 / 2.442 / 6.618 / 6.908 / 2.524 /
2.991 / 2.651 / 1.998 / Overall 44.95
VIPER ext2 patched, DK17 VIPERrom FroYo:
0.971 / 2.758 / 2.745 / 0.091 / 0.073 / 0.989 / 2.488 / 6.749 / 6.951 / 1.68 /
1.21 / 1.227 / 0.308 / Overall 28.24
(For comparison:
Normal, rfs, Korean M110S Galaxy S, SK22 FroYo (moviNAND)
81.281 / 5.857 / 4.107 / 0.251 / 0.117 / 1.221 / 2.26 / 7.181 / 13.065 / 4.359 / 7.754 / 10.481 / 11.135 / Overall 149.069)
The answer is obvious: ext2 increases I/O performance.
The new questions are:
1) is ext3 or ext4 better than ext2?
2) is it safe to use ext2 on OneNAND devices?
(there are several debates about ext's on moviNAND as well.)
Forgot to mention: it is not possible to support ext3 or 4 at the moment for FroYo now, since there is no source code released yet. (which is of course thing; there is no official froyo yet lol)
chocoberry said:
Forgot to mention: it is not possible to support ext3 or 4 at the moment for FroYo now, since there is no source code released yet. (which is of course thing; there is no official froyo yet lol)
Click to expand...
Click to collapse
If you had been following the Quantum Rom thread, you would have seen that the "Lagfix" was nothing more than a joke to prove a point about Quadrant, and other epic roms using a lagfix.
Froyo is not complete yet, there is no source, there is still debugging code, and it is not optimized for release. This will explain all low scores. Also; issuing a ton of sqlite queries hardly amounts to real life performance on a phone, and once again it is all I/O. (As sqlite is stored in files.) (And yes, I am aware that we use sqlite to store data. But we don't do thousands of transactions in an operation... ever) The same thing happens when you loop an ext FS over RFS, you get inflated values because of the ram buffer between RAM and ext filesystem.
When froyo goes official; I will try my hand at porting a ext4 fs to the epic (Minus journaling, as it kills performance); but Samsung is making improvements to rfs, and the results are getting better. However, you need to realize that I/O performance is not all that matters on a phone, and regardless there are other aspects that will throttle you anyway.
Dameon87 said:
you need to realize that I/O performance is not all that matters on a phone, and regardless there are other aspects that will throttle you anyway.
Click to expand...
Click to collapse
Yes you are true. For epic it's not the I/O which makes bottleneck (not like other SGS), obviously, because it is already on top of all Android devices even with rfs, thanks to OneNAND flash.
But the purpose of thread and benchmark is to test "if" the file system change will increase I/O performance or not on OneNAND devices (which now runs on Sammy's propriety driver). And my conclusion is that it "does" increase performance. That's all. I know that you are a ROM developer (and I'm a Quantum ROM user also) who hears tons of useless quadrant things, but you don't have to do that to me. You overinterpreted the data; I don't want to emphasize or imply anything.
chocoberry said:
Yes you are true. For epic it's not the I/O which makes bottleneck (not like other SGS), obviously, because it is already on top of all Android devices even with rfs, thanks to OneNAND flash.
But the purpose of thread and benchmark is to test "if" the file system change will increase I/O performance or not on OneNAND devices (which now runs on Sammy's propriety driver). And my conclusion is that it "does" increase performance. That's all. I know that you are a ROM developer (and I'm a Quantum ROM user also) who hears tons of useless quadrant things, but you don't have to do that to me. You overinterpreted the data; I don't want to emphasize or imply anything.
Click to expand...
Click to collapse
Oh no. I wasn't trying to come off as an ass at all. I was just giving some information.
We will not know any concrete evidence until official 2.2 is released as sammy has been working on rfs.
Sent from my SPH-D700 using Tapatalk
As I said before..the lagfix would make the phone into a nice database server lol
But part of deploying a database has always been choosing the right file system...:/
Its not like you won't get any increase at all in real life performance...I'd probably guess at around 1% or so..but obviously not enough to justify what people perceive Quadrant shows...hence if your not using Quadrant Pro..really no point of using Quadrant much :/
Dameon87 said:
When froyo goes official; I will try my hand at porting a ext4 fs to the epic (Minus journaling, as it kills performance); but Samsung is making improvements to rfs, and the results are getting better. However, you need to realize that I/O performance is not all that matters on a phone, and regardless there are other aspects that will throttle you anyway.
Click to expand...
Click to collapse
isnt ext2 the fast one, ext 3 the data secure one, and ext4 the best of both worlds? when you removing journaling isnt that basically going to just drop it down to ext2?
"All Samsung Roms run on top of BML/RFS, CyanogenMod 7 does NOT.
It runs on MTD/yaffs2 (like Nexus One) which means you'll not able to flash just any kernel or run just any other filesystem you want. Use it as it is if possible, otherwise confirm with the kernel developer that you are trying to install whether it would work with CM. We do not support other kernels and know nothing about their capabilities or compatibility. Only the data partition, which is on movinand, is ext4 like on speedmod or voodoo ("lagfix"). No "lagfix" is necessary because this does not use any Samsung proprietary file systems."
This is a quote from Atinm about the CM7 nightlies.
I'm a bit confused on what it all means.
I know the stock filesystem on our phone is RFS, and then we apply the voodoo lagfix on previous roms to change over to Ext4 to speed things up.
Now what does this mean that the filesystem is now MTD/yaffs2? Is this a better or worse filesystem then EXT4? I'm just curious to know.
yaffs2 is more optimized for flash media than ext4 or rfs/fat. ext4 is more about speed especially on larger drives, but it is media-agnostic. yaffs2 is more focused on data integrity which comes in handy with flash media where you have cycling pages of data that can go bad sometimes. Which isn't to say it's slower either though. Pretty much anything is faster than RFS
So then why was RFS used in the first place? Confusing....
jwleonhart said:
So then why was RFS used in the first place? Confusing....
Click to expand...
Click to collapse
First you have to understand the difference between the partition types.
With flash media, you need something to control wear leveling, whether it be a hardware controller or the filesystem. Bml is essentially a "box" with wear leveling controlled by hardware. This allows you to use common filesystems like RFS (a fat derivative) or voodoo lagfix's ext4. But why Samsung chose this over mtd/yaffs2, no one but the engineers at Samsung knows.
Mtd is the partition type used my the nexus phones, HTC phones, and Google's aosp code. It is essentially a partition of raw flash media, that bypasses any sort of hardware wear leveling. Because of this, you need a filesystems that does this for you, and that's what yaffs2 was designed for. It is not, however, the same as ext4, as ext4 is still meant for conventional mechanical hard drives, al though there are things added in for ssd's but they still require a controller. Yaffs2 is very different different from ext4.
Sent from my SGH-T959 using XDA App
So the question still remains... whats the difference?
Wear leveling would be better do ensure lifr of the internal sd would it not? Does samsung put high quality chip in these phones even?
Sent from my SGH-T959 using XDA Premium App
jwleonhart said:
So the question still remains... whats the difference?
Wear leveling would be better do ensure lifr of the internal sd would it not? Does samsung put high quality chip in these phones even?
Sent from my SGH-T959 using XDA Premium App
Click to expand...
Click to collapse
No, it's not that. It's Tue way current nand flash memory is. That's why there are constantly new controllers coming out for ssds, and constantly new development on filesystems perfectly suited for raw flash memory.
Running a conventional mechanical based filesystems on raw nand would destroy it because it would be constantly writing to the nand memory cell, and you want the exact opposite.
It gets very technical to go any deeper into an explanation, but the reason why CM7 is going with mtd us that their bread and butter (HTC devices, and the nexus series as well as the aosp code) is mtd.
Sent from my SGH-T959 using XDA App
What if it was a filesystem like NTFS? Just for example lets say it could run FAT32.
jwleonhart said:
What if it was a filesystem like NTFS? Just for example lets say it could run FAT32.
Click to expand...
Click to collapse
Ntfs was built for.mechanic hard drives, and would have to rely on a controller to protect the nand flash.
Sent from my SGH-T959 using XDA App
I wouldn't mind a 500gb hard drive in mah phone yooo
It sounds like everyone would benefit from using this script, but there's no specific guidance for the MyTouch 4G. I assume option 8 or 9 would be best since the phone has 512MB of ram.
Are there some roms that we shouldn't be using V6 SuperCharger with?
Link to V6 SuperCharger: http://forum.xda-developers.com/showthread.php?t=991276
You're wrong on 2 points (possibly more):
1) This script is just the same as Autokiller app, with a small addition - it can (or can't) keep launcher in memory. Nothing new and revolutionary. This app exists for a couple of years.
2) This phone has 768MB of RAM. It won't benefit from a low memory killer (or actually, different settings for an existing in OS lowmemkiller), because it has TONS of memory. I just took a look at my phone, ~100MB of memory free, and ~300MB of remaining memory is taken by CACHED apps. If you don't know what it means - please read up on Android memory management, and I'll give you the short version - it's the same as free memory, but better.
It states in the first post:
Also Note: Nothing else does what The V6 SuperCharger does!
................Not AutoKiller Memory Optimizer, Not Auto Memory Manager, Not Minfree Manager...
The Nook Color has 512 MB of ram and people have noticed a big difference using this script on Cyanogenmod.
but since the Glacier has 768MB of ram, you won't notice much change.
saranhai said:
but since the Glacier has 768MB of ram, you won't notice much change.
Click to expand...
Click to collapse
I have found it useful on ports and ROMs that aren't tweaked specifically for this phone. For instance, if TDJ made the ROM, V6 is useless. In fact, it will only hurt.
Sent from my HTC Glacier using XDA App
I use this script on my evo and its great so I just rooted this phone and flashed the mik runny ROM, I was using it for a day and only stayed at about 100mb of RAM so I decided to use v6 with option 8 and now it stays around 200mb and is running super smooth.
IDK if that helps any but I always loved v6 and know a few people that use it on a few different phones and it always works for the better.
Sent from my HTC Glacier using XDA App
Why do people that know nothing or close to nothing about OS internals, decide that they have better knowledge of memory management should be, then OS and phone designers? The same people who don't know the difference between cached and active apps, and the only number they understand is the (useless) amount of free memory? I see it all over the forums, and it amazes me each time. How do people actually try to judge if something works well or not, without getting at least some basic understanding of how the things work?
Oh well, here it comes again:
http://forum.xda-developers.com/showthread.php?t=678205
Read this. Maybe you will understand something.
Few, if any, 512MB phones and no 768MB phones need this script, or any kind of tweaking for lowmemkiller values, especially not since Gingerbread and when not running Sense (which retains the ability to cache apps, removed in Gingerbread mostly to ease running the OS on older devices). The only thing it does, is to make garbage collector work harder and kick in earlier. It doesn't make your phone "smoother", and whoever think it does - should check the meaning of the word "placebo" in the nearest dictionary. The number that stands for "free memory" means something between "close to nothing" and "absolutely nothing".
I know I shouldn't be surprised, people always tend to have strong opinions on everything, even things they sometimes don't know a thing about. But still, it's XDA-Developers, not XDA-Phone-users, so at least something should be done about it. Even if the education attempts will fail, like they mostly do.
Jack_R1 said:
Why do people that know nothing or close to nothing about OS internals, decide that they have better knowledge of memory management should be, then OS and phone designers? The same people who don't know the difference between cached and active apps, and the only number they understand is the (useless) amount of free memory? I see it all over the forums, and it amazes me each time. How do people actually try to judge if something works well or not, without getting at least some basic understanding of how the things work?
Oh well, here it comes again:
http://forum.xda-developers.com/showthread.php?t=678205
Read this. Maybe you will understand something.
Few, if any, 512MB phones and no 768MB phones need this script, or any kind of tweaking for lowmemkiller values, especially not since Gingerbread and when not running Sense (which retains the ability to cache apps, removed in Gingerbread mostly to ease running the OS on older devices). The only thing it does, is to make garbage collector work harder and kick in earlier. It doesn't make your phone "smoother", and whoever think it does - should check the meaning of the word "placebo" in the nearest dictionary. The number that stands for "free memory" means something between "close to nothing" and "absolutely nothing".
I know I shouldn't be surprised, people always tend to have strong opinions on everything, even things they sometimes don't know a thing about. But still, it's XDA-Developers, not XDA-Phone-users, so at least something should be done about it. Even if the education attempts will fail, like they mostly do.
Click to expand...
Click to collapse
I do understand that in some cases you don't need a memory manager like if your running a stock ROM or an aosp ROM that doesn't take up as much memory.
Now I haven't had this phone long enough to say if this script is all that good for this phone but I know on the evo running a sense 3.0-3.5 ROM that wasn't meant for the phone and hugs up every little bit of memory that the phone has to offer, this scrip makes those ROMs usable.
Without it or something like it the phone can't handle doing simple tasks like using an app without fc something else like the launcher.
So you could say what you want and yes maybe this phone doesn't need it since it has more RAM and ROM but I'll still try things like this to try and see if it will better the phones performance.
Sorry if that doesn't make sense I'm still half asleep.
Sent from my HTC Glacier using XDA App
The instances where i have noticed that this works is while doing benchmarking with quadrant. It has shown increased framerates for me after running the script and I also get higher scores on quadrant, about 500-1k more than without. I dont know if its usefull for much other than benchmarking though. I think the phone runs fine without it though.
What you have to understand is performance is not measured via syntactic benchmarks (ex: Quadrant). The biggest issue with people is that they don't know enough to know that they don't know, so they compare it with silly numbers (ex: score) they can't comprehend what they see, much less put numbers behind real life activities that's not applicable in controlled environment.
Now far as V6-SC script goes its almost obsolete now due to few things. 1) Hardware advancement where now minimum spec requirements for "SmartPhone" are 1ghz single core proc with 512mb ram. But so called "SuperPhone" now has dual core 1ghz-1.5ghz with 768mb-1gb ram. So it make no sense as we don't use 256-566mhz proc with 64-256mb ram because we are more then enough hardware adequate for heavy daily usage. 2) OS development which elements most of it as hardware is more and more powerful. But on software level mostly all custom base rom (ex: CyanogenMod) is highly optimized and tweaked to run on optimal performance.
Now is it all placebo effect? Mostly, but not all. But does it mean it can't be tweaked any further? (Rhetorical) No. How do I know? We (scope outside of XDA) tweaked it to the next level. How you ask?
1) Optimized ext4fs: reduced r/w rate (healthy NAND lifespan), improved journaling (corrupted data writeback integrity) = Which improves the IOPs and performance access rate.
2) HC3.x fugu binaries, patched sqlite libraries, mSD read ahead buffer fix.
3) Modified VM: OOM (Out Of Memory), LMK (Low Memory Killer), VM heap (Virtual Machine), DRA (Dirty Ratio), DBR (Dirty Background Ratio), DWC (Dirty Writeback Centisecs), DEC (Dirty Expired Centisecs), SWP (Swap), VCP (VFS Cache Pressure).
4) Increased minfree value: Background, Foreground, Empty, Hidden, Visible, Secondary, Content.
5) Optimized cache: File and Drop cache, Forced cache (resident loop).
6) Custom kernel: OC/UC, UV/SVS/VDD, BFS/CFS, RSU/VR/SP supported.
7) Custom ROM: Optimized Rom script and props (ex: CyanogenMod).
I bet my superior MT4G can own your inferior MT4G. Cuz you can't touch this as its tweaked to THE next level. I'll stick with AOSP2.3.7GB until ICS4.X is more stable and we understand more as most memory grouping and adjustments might be changed.
Sent from my HTC Glacier
Jack_R1 said:
You're wrong on 2 points (possibly more):
1) This script is just the same as Autokiller app, with a small addition - it can (or can't) keep launcher in memory. Nothing new and revolutionary. This app exists for a couple of years.
2) This phone has 768MB of RAM. It won't benefit from a low memory killer (or actually, different settings for an existing in OS lowmemkiller), because it has TONS of memory. I just took a look at my phone, ~100MB of memory free, and ~300MB of remaining memory is taken by CACHED apps. If you don't know what it means - please read up on Android memory management, and I'll give you the short version - it's the same as free memory, but better.
Click to expand...
Click to collapse
Obviously, you never tried it lol
Here... you may learn something new...
http://www.rt-embedded.com/blog/archives/linux-memory-consumption/
http://forum.xda-developers.com/showpost.php?p=20163493&postcount=6695
Below a certain threshold of free ram (ie. not enough cached), the device WILL gag...
Hundreds if not thousands of users with 1 GB ram devices use it (Atrix, SGSII, etc.) and I know your phone stutters from time to time with a slight delay when pressing buttons from time to time since that's what my friend's Atrix does.
In fact, the biggest difference he notices is in the use of google maps... never a stutter.
So you're missing out.
zeppelinrox said:
[1] Obviously, you never tried it lol
[2] I know your phone stutters from time to time with a slight delay when pressing buttons from time to time since that's what my friend's Atrix does.
[3] So you're missing out.
Click to expand...
Click to collapse
First of all as dev of V6-SC you would be very defensive but at same times your not charging money to normal folks for it is a good thing, so thank you. Which I can say less about other folks editing same value claiming it new. Now I don't know about Jack but let's be clear on few points.
1) I did try your so called script and didn't like the whole script manger + busybox cast AFTER the OS startup. Which normally you can achieve via daemon or init.d script after kernel is initialized by declaring and using native shell. So no need for force apply afterwards as it was utilized before it was initiated via script manager. Also V6-SC couldn't keep the selected category minfree value which changed. But in short I didn't notice anything revolutionary as it was fully optimized long before I randomly landed on Android General section and saw your post claiming it maximize the devices performance. Which I was spectacle about as from your post you did seem to have basic knowledge hopefully not from wiki/google but *nix usr exp before landing on to Android.
2) Like I said I don't know about Jacky Boy but I can GRANTEE you I have NEVER had this so called "button delay" you specified. But I did modify the sampling rate and pressure density accommodated by tweaking transition speed. But now I run min:368mhz/max:1027mhz/gov:SmartAssV2. But even when I was battery conscience before I had MP1650mAh I ran on min:230mhz/max:768mhz/gov:SmartAssV1 with custom -75 to -100 VDD using ~14mA idle and ~60-90mA active per unit scale. I never had lag with 200mb used RAM running at least 18-20pcs and 14-15svc. So what your friend is running (Atrix) is irrelevant also isolated.
3) O-RLY am I really missing out? I think ill stick to my own. But don't take this post personal as it was ment for it to be argumentative. Difference is I actually know what I'm talking about as I have strong backgrounds on...
Sent from my HTC Glacier
zeppelinrox said:
Obviously, you never tried it lol
Here... you may learn something new...
http://www.rt-embedded.com/blog/archives/linux-memory-consumption/
http://forum.xda-developers.com/showpost.php?p=20163493&postcount=6695
Below a certain threshold of free ram (ie. not enough cached), the device WILL gag...
Hundreds if not thousands of users with 1 GB ram devices use it (Atrix, SGSII, etc.) and I know your phone stutters from time to time with a slight delay when pressing buttons from time to time since that's what my friend's Atrix does.
In fact, the biggest difference he notices is in the use of google maps... never a stutter.
So you're missing out.
Click to expand...
Click to collapse
I didn't need to try it to know. I tried Autokiller, I played with lowmemkiller settings and watched the results, and I did it on Nexus One with 512MB of memory. It never needed anything since Gingerbread, and unless I made the settings super-aggressive, Autokiller actually failed to make any difference whatsoever - the apps were killed based on their age and never dropped by replacing apps.
In the current system, I have 100MB free + 250MB cached apps (which is just the same as free - theoretically and practically). The main difference you're not accounting for is - Android isn't a Linux distro, it's a Linux-derived OS, with many changes for mobile activity, especially on the kernel level, especially in the memory management area. "Linux memory consumption" isn't Android memory consumption, since they manage things differently. Linux isn't build to kill running apps, its lowmemkiller can't do it. Linux doesn't have concurrent garbage collector. Many Linux examples are irrelevant. Cached apps in Android aren't cached pages in Linux, freeing cached pages in Linux isn't killing cached apps in Android, and the most important - "performance degradation" doesn't exist in Android, since you ALWAYS have enough memory for any size of task (the largest loading task requires 50MB of memory, and there's 100MB free on my phone), and concurrent garbage collection is ALWAYS present in the system, the only thing you're doing - is calling it earlier, making it actually work more and getting the system more laggy than it could be.
I understand that you want to protect your creation, but in this case, you're wrong, sorry. You won't convince me.
And yes, I don't know what "button lag" are you talking about.
HTC Glacier said:
First of all as dev of V6-SC you would be very defensive but at same times your not charging money to normal folks for it is a good thing, so thank you. Which I can say less about other folks editing same value claiming it new. Now I don't know about Jack but let's be clear on few points.
1) I did try your so called script and didn't like the whole script manger + busybox cast AFTER the OS startup. Which normally you can achieve via daemon or init.d script after kernel is initialized by declaring and using native shell. So no need for force apply afterwards as it was utilized before it was initiated via script manager. Also V6-SC couldn't keep the selected category minfree value which changed. But in short I didn't notice anything revolutionary as it was fully optimized long before I randomly landed on Android General section and saw your post claiming it maximize the devices performance. Which I was spectacle about as from your post you did seem to have basic knowledge hopefully not from wiki/google but *nix usr exp before landing on to Android.
2) Like I said I don't know about Jacky Boy but I can GRANTEE you I have NEVER had this so called "button delay" you specified. But I did modify the sampling rate and pressure density accommodated by tweaking transition speed. But now I run min:368mhz/max:1027mhz/gov:SmartAssV2. But even when I was battery conscience before I had MP1650mAh I ran on min:230mhz/max:768mhz/gov:SmartAssV1 with custom -75 to -100 VDD using ~14mA idle and ~60-90mA active per unit scale. I never had lag with 200mb used RAM running at least 18-20pcs and 14-15svc. So what your friend is running (Atrix) is irrelevant also isolated.
3) O-RLY am I really missing out? I think ill stick to my own. But don't take this post personal as it was ment for it to be argumentative. Difference is I actually know what I'm talking about as I have strong backgrounds on...
Sent from my HTC Glacier
Click to expand...
Click to collapse
Sounds like you never got it working properly.
Also, if you have init.d support no need to run anything on boot with script manager.
Maybe the rom's kernel was applying settings late.
And no my friends atrix is not isolated there is a rather big thread in the atrix forums.
SGSII users see benefits too so seems there is always room for improvement.
Jack_R1 said:
I didn't need to try it to know. I tried Autokiller, I played with lowmemkiller settings and watched the results, and I did it on Nexus One with 512MB of memory. It never needed anything since Gingerbread, and unless I made the settings super-aggressive, Autokiller actually failed to make any difference whatsoever - the apps were killed based on their age and never dropped by replacing apps.
In the current system, I have 100MB free + 250MB cached apps (which is just the same as free - theoretically and practically). The main difference you're not accounting for is - Android isn't a Linux distro, it's a Linux-derived OS, with many changes for mobile activity, especially on the kernel level, especially in the memory management area. "Linux memory consumption" isn't Android memory consumption, since they manage things differently. Linux isn't build to kill running apps, its lowmemkiller can't do it. Linux doesn't have concurrent garbage collector. Many Linux examples are irrelevant. Cached apps in Android aren't cached pages in Linux, freeing cached pages in Linux isn't killing cached apps in Android, and the most important - "performance degradation" doesn't exist in Android, since you ALWAYS have enough memory for any size of task (the largest loading task requires 50MB of memory, and there's 100MB free on my phone), and concurrent garbage collection is ALWAYS present in the system, the only thing you're doing - is calling it earlier, making it actually work more and getting the system more laggy than it could be.
I understand that you want to protect your creation, but in this case, you're wrong, sorry. You won't convince me.
And yes, I don't know what "button lag" are you talking about.
Click to expand...
Click to collapse
I was tempted to stop reading when you admit to not even using it.
If it did the same as AKMO or Auto Memory Manager why on earth would anybody bother.
I sure as hell wouldn't bother writing a 4500+ line script lol.
I totally agree that Android memory is not the same as linux (see my sig) but the similarities are there and the article I posted applies 100%.
Its not about free ram.
Its about the right balance.
In fact, many report LESS free ram, ie. better multitasking, along with better performance and smoother performance.
Because I don't think Android memory should work the same as linux memory either.
Also, you tried AKMO because you felt there could be improvement and it didn't work.
THAT'S why I wrote a 4500+ line script that blows anything else out of the water
zeppelinrox said:
Sounds like you never got it working properly.
Also, if you have init.d support no need to run anything on boot with script manager.
Maybe the rom's kernel was applying settings late.
And no my friends atrix is not isolated there is a rather big thread in the atrix forums.
SGSII users see benefits too so seems there is always room for improvement.
Click to expand...
Click to collapse
Well my highly optimized as is but I am aware of V6 and others using it but personally I would stick to my.
Sent from my HTC Glacier
I think its better to Post this here,when its not better,than sorry!!!
-----------------------------------------------------------------
Once a brief statement for those who are not traveling so long in the Android scene:
ZRAM = ramzswap = Compcache
In order to explain more precisely ZRAM first need other terms are more clearly defined:
Swap can be compared with the swap file on Windows. If the memory (RAM) to complete the PC the data that are being used not actively outsource (eg background applications) so as to re-evacuate RAM free. To this data is written to a hard disk. If required, this data is then read back from there easily. Even the fastest SSD is slower than the RAM. On Android, there is no swap!
In ZRAM unnecessary storage resources are compressed and then moved to a reserved area in the fixed RAM (ZRAM). So a kind of swap in memory.
This Ram is more free because the data then only about 1/4 of the former storage requirements have. However, the CPU has to work in more because they compress the data has (or unpack again when they are needed). The advantage clearly lies in the speed. Since the swap partition in RAM is much faster than this is a swap partition on a hard drive.
In itself a great thing. But Android does not have a swap partition, and therefore brings Android ZRAM under no performance gain as would be the case with a normal PC.
In normal PC would look like this:
Swap = swap file (on disk) -> Slow
ZRAM (swap in RAM) -> Faster than swap
RAM -> Quick
With Android, there is no swap partition, and therefore brings ZRAM also no performance boost.
The only thing that brings ZRAM is "more" RAM. Compressed by the "enlarged" so to speak of the available memory. That's on devices with little RAM (<256MB) also pretty useful. The S2 has 1GB but the rich, and more than. There must not be artificially pushed up to 1.5 GB.
After you activate the ZRAM also has 2 disadvantages. The encoding and decoding using CPU time, which in turn has higher power consumption.
Roughly one can say (For devices with more than 512MB RAM):
Without ZRAM: + CPU Performance | + Battery | RAM
With ZRAM: CPU Performance |-Battery | + RAM
For devices with too little RAM so it makes perfect sense. But who shoots the S2 already be fully complete RAM and then still need more?
Check whether you can ZRAM runs in the terminal with
free or cat / proc / meminfo
I hope it helps to understand zRam!!!!
Thanks for the info
Yeah thanks indeed for the info - so does this mean that we must have zram disabled because of low memory ?
no its very good for devices with less ram like 289mb and we have less ram,so its useless for higher ram devices with 800-1000,but that can u read in this guide
CALIBAN666 said:
no its very good for devices with less ram like 289mb and we have less ram,so its useless for higher ram devices with 800-1000,but that can u read in this guide
Click to expand...
Click to collapse
Yeah i misunderstood thanks for explaining !
But one more doubt - its good for us anyhow if we disable it will we get more free ram ?
in your statement zram is not battery friendly. ? am i correct. ? or not?
Sorry for too many questions mate - am the noobest guy here on xda that is why
not really because the system all the time creates virtual ram and distributed, just as if the ram is not needed, because then the virtual ram not needed and the system distributes it then falls to a normal ram, but I think it also comes to the what and how much the device is made for running multiple concurrent tasks, it is recommended.
nikufellow said:
Sorry for too many questions mate - am the noobest guy here on xda that is why
Click to expand...
Click to collapse
no problem bro,thats the reason why i open this thread.and hey im noob too
Thank you
one of the best information thread on forum
thank you mate
ewat said:
in your statement zram is not battery friendly. ? am i correct. ? or not?
Click to expand...
Click to collapse
Yes you are correct as cpu will have to do more work compresshog and de compressing stuff so more power will be consumed
Nice guide
But still i dont get it
post source : www.posting-a-post-at-tapatalk.com
@CALIBAN666
ramzswap != compcache. both using compressed data on memory. both even from the same person AFAIR. the different is ramzswap using compressed swap and compcache using compressed cache.
kernel 2.6.35 source code from samsung have ramzswap support, but you need user space program to enable it (need little patch to build it for sgy but it's easy).
irfanbagus said:
@CALIBAN666
ramzswap != compcache. both using compressed data on memory. both even from the same person AFAIR. the different is ramzswap using compressed swap and compcache using compressed cache.
kernel 2.6.35 source code from samsung have ramzswap support, but you need user space program to enable it (need little patch to build it for sgy but it's easy).
Click to expand...
Click to collapse
Can u help me on enabling ramzswap?? Zram is laggy
Sent from my GT-S5360 using XDA
hell_lock said:
Can u help me on enabling ramzswap?? Zram is laggy
Sent from my GT-S5360 using XDA
Click to expand...
Click to collapse
i follow this instruction but using build-in ramzswap.ko in sgy kernel source. the trivial part is compile rzscontrol for sgy. i forget how i build it but AFAIR need few patching. i'll post if i find it.
Not understood... Android has no swap? Then what is swapper for? Swapping partition?
I tried swapper for my galaxy y n i didnt liked it personally
By that time i had stock sd card
Im gonna try zram on my 16 gb class 6 sd card..i wish this thing works for me cuz after installing merruk kernel, my 50 mb ram got stuck
Sent from my GT-S5360 using xda app-developers app
swapp != zram
Rcain said:
Not understood... Android has no swap? Then what is swapper for? Swapping partition?
Click to expand...
Click to collapse
With swapper you can have an swap file or you can choose to partition your SD-Card to have an swap partition there. Swap is not used by default in Galaxy Y and swap space is optional not really needed in Android (or Unix/Linux in general).
On the other hand, zram is a whole different beast.
If I'm not mistaken a dev for ace2 already made it several month ago. It using init.d script to control the zram stuff