So everyone (including me) has noticed that the transformer slows down when doing i/o. I originally thought this was a hardware issue (slow memory? slow bus?) but from various threads it sounds like third party os fix the issue. So I have two questions:
Can someone explain what the asus kernel does wrong (or how third party kernels) fix the issue ?
Why asus cannot copy the fixes from third party kernels into their kernel (I presume this is a kernel issue and not support software around the kernel but maybe that presumption is incorrect; maybe it is a driver issue or maybe there really is a hardware issue?)
jake21 said:
So everyone (including me) has noticed that the transformer slows down when doing i/o. I originally thought this was a hardware issue (slow memory? slow bus?)
Click to expand...
Click to collapse
Random write of small blocks to the internal eMMC is slow. Flash memory has huge erase blocks (typically a couple of megabytes) and large write blocks. Writing 4KB is a relatively slow process.
jake21 said:
but from various threads it sounds like third party os fix the issue.
Click to expand...
Click to collapse
They can't fix it, they can only work around the issue by tweaking the kernel's caching parameters. Or, in the extreme case, disabling the fsync system call. Usually, an application calls fsync to ensure data has been written to the disk, so that even in case of a following crash or unexpected power loss the data on the medium is consistent. And normally fsync waits until the write command has completed. If you disable fsync, the app no longer has to wait, therefore no more lag. The data still resides in the RAM and is eventually written to the card by the background cache flush thread.
Downside of disabling fsync: If the tablet crashes in the wrong moment, you may in the worst case lose all your data, run into a bootloop, etc.
If this is true, how come with original release ICS 4.0.3 everything runs smooth and fast. I installed latest Jelly Bean 4.1 and slow real bad, i downgraded back to ICS 4.03 and it is fast again. Is it a driver issue. It can't be hardware.
Thanks
_that said:
Random write of small blocks to the internal eMMC is slow. Flash memory has huge erase blocks (typically a couple of megabytes) and large write blocks. Writing 4KB is a relatively slow process.
They can't fix it, they can only work around the issue by tweaking the kernel's caching parameters. Or, in the extreme case, disabling the fsync system call. Usually, an application calls fsync to ensure data has been written to the disk, so that even in case of a following crash or unexpected power loss the data on the medium is consistent. And normally fsync waits until the write command has completed. If you disable fsync, the app no longer has to wait, therefore no more lag. The data still resides in the RAM and is eventually written to the card by the background cache flush thread.
Downside of disabling fsync: If the tablet crashes in the wrong moment, you may in the worst case lose all your data, run into a bootloop, etc.
Click to expand...
Click to collapse
Ok I can understand the issue with fsync and small writes but then all tablets would have this issue (unless the infinity used particularly poor chioce of hardware). Also does this indicate if writes were disabled in (for example) browsers then they would be silky smooth ?
-
It would be nice if the tablet could mark certain directories as critical and flush those faster than other directories (perhaps abusing the meaning of the sticky bit on the directory). Certain non critical data can avoid having immediate flush (though if andriod apps are calling fsync explicitly there might be some stickyness in changing the behavior of the api). Anyways is my understanding correct that you are indicating that Asus used a particularly poor choice of eMMC or tweaked the kernel to flush more frequently ?
_that said:
Random write of small blocks to the internal eMMC is slow. Flash memory has huge erase blocks (typically a couple of megabytes) and large write blocks. Writing 4KB is a relatively slow process.
They can't fix it, they can only work around the issue by tweaking the kernel's caching parameters. Or, in the extreme case, disabling the fsync system call. Usually, an application calls fsync to ensure data has been written to the disk, so that even in case of a following crash or unexpected power loss the data on the medium is consistent. And normally fsync waits until the write command has completed. If you disable fsync, the app no longer has to wait, therefore no more lag. The data still resides in the RAM and is eventually written to the card by the background cache flush thread.
Downside of disabling fsync: If the tablet crashes in the wrong moment, you may in the worst case lose all your data, run into a bootloop, etc.
Click to expand...
Click to collapse
gordo2000 said:
If this is true, how come with original release ICS 4.0.3 everything runs smooth and fast. I installed latest Jelly Bean 4.1 and slow real bad, i downgraded back to ICS 4.03 and it is fast again. Is it a driver issue. It can't be hardware.
Click to expand...
Click to collapse
I didn't see a big performance difference between ICS and JB, even though JB should be even faster after all the "Project Butter" work. What is slow for you on JB?
---------- Post added at 07:35 PM ---------- Previous post was at 07:30 PM ----------
jake21 said:
Ok I can understand the issue with fsync and small writes but then all tablets would have this issue (unless the infinity used particularly poor chioce of hardware). Also does this indicate if writes were disabled in (for example) browsers then they would be silky smooth ?
Click to expand...
Click to collapse
Many people said the TF700's eMMC is slower than good microSD cards, and that can be reproduced with benchmarks.
To check how the browser performs if it doesn't have to write to the eMMC, install Browser2RAM, which moves the browser cache to a ramdisk. In my experience, there is still lag on some pages - so not all slowdowns seem to be I/O-related. It would be interesting to find out the real cause of this.
There may be another I/O situation except random writes: large writes which block small reads from another process. HPI should help here, but I think the 3.1 kernel doesn't support it yet.
_that said:
I didn't see a big performance difference between ICS and JB, even though JB should be even faster after all the "Project Butter" work. What is slow for you on JB?
---------- Post added at 07:35 PM ---------- Previous post was at 07:30 PM ----------
Many people said the TF700's eMMC is slower than good microSD cards, and that can be reproduced with benchmarks.
To check how the browser performs if it doesn't have to write to the eMMC, install Browser2RAM, which moves the browser cache to a ramdisk. In my experience, there is still lag on some pages - so not all slowdowns seem to be I/O-related. It would be interesting to find out the real cause of this.
There may be another I/O situation except random writes: large writes which block small reads from another process. HPI should help here, but I think the 3.1 kernel doesn't support it yet.
Click to expand...
Click to collapse
Agreed. However, even with Browser2Ram, I'm betting that there is still some i/o with the emmc that cannot be hijacked by broser2ram, and therein lies the problem. If nothing else, using RAM like that may force the tablet (b/c of screwy coding) to start paging data to...yup, you guessed it, emmc ... a lot sooner than it actually needs to.
Has anyone tried B2R along with dev settings to kill apps ASAP that are not in use? Perhaps this could lengthen the time before paging starts to occur?
Sent from my ASUS Transformer Infinity TF700 running Android JB (rooted) via Tapatalk
Overall, everything runs smooth on ICS 4.0.3. Browser, opening app, games, there is no hick ups when watching movies, that happen alot on JB 4.1.1. The whole OS is smoth redrawing. On JB, there is always a wait few seconds to open application folders or closing it. I did reformat to default but no help.
_that said:
I didn't see a big performance difference between ICS and JB, even though JB should be even faster after all the "Project Butter" work. What is slow for you on JB?
---------- Post added at 07:35 PM ---------- Previous post was at 07:30 PM ----------
Many people said the TF700's eMMC is slower than good microSD cards, and that can be reproduced with benchmarks.
To check how the browser performs if it doesn't have to write to the eMMC, install Browser2RAM, which moves the browser cache to a ramdisk. In my experience, there is still lag on some pages - so not all slowdowns seem to be I/O-related. It would be interesting to find out the real cause of this.
There may be another I/O situation except random writes: large writes which block small reads from another process. HPI should help here, but I think the 3.1 kernel doesn't support it yet.
Click to expand...
Click to collapse
johnlgalt said:
Agreed. However, even with Browser2Ram, I'm betting that there is still some i/o with the emmc that cannot be hijacked by broser2ram, and therein lies the problem.
Click to expand...
Click to collapse
Not all I/O automatically leads to problems. The latest version of Browser2RAM only redirects the browser cache, it does not affect browser settings, bookmarks, etc. - which is usually a good thing.
johnlgalt said:
If nothing else, using RAM like that may force the tablet (b/c of screwy coding) to start paging data to...yup, you guessed it, emmc ... a lot sooner than it actually needs to.
Click to expand...
Click to collapse
No. Paging does not occur *to* the eMMC (no swap space is configured on the TF700), but only *from* the eMMC, to fetch pages of executable files. While it is true that the ramdisk for the cache uses some memory, it would only make a difference if you have lots of background apps competing for RAM.
A first step to see how much I/O happens is to watch the output of "iostat".
Thanks for the heads up. So, why does it still cause pauses and the like then?
Sent from my ASUS Transformer Infinity TF700 running Android JB (rooted) via Tapatalk
johnlgalt said:
So, why does it still cause pauses and the like then?
Click to expand...
Click to collapse
Good question. It's time to find out.
Arm yourself with multiple adb shells and watch the output of iostat, top, free, or whatever else you can think of that displays interesting metrics. Then do something that causes lag and see if you notice a specific pattern.
(I am currently away from my main PC, and the SSD in my laptop decided yesterday it no longer wants to read ntkrnlpa.exe - so no adb for me right now)
I'll need a bit more specifics - I know adb well enough and can shell, but these other ... executables you're mentioning are new to me.
I'm on vacation in Hawaii, and have a Windows 7 based laptop that I can use, so I can do this no problem - but not today. About to go see some sights before going on a Lava Boat tour at 4 PM local, which means I'll be bushed when I get back - plus I'm fighting a nasty ear infection that aches something awful.
AFAIK, though, I have no real plans for tomorrow or Friday, so I can take some time and investigate.
Also, FWIW: I'm rooted but have not (yet) unlocked my bootloader - mainly b/c I purchased the 64 GB version of the tablet and it is a C50, so I'm hoping something 'breaks' enough for me to get a replacement (c70? C90 even? )- and hoping even more that it is running something under ICS .30 so I can nvflash a backup and not have to worry about goofing things up when I *do* unlock the bootloader.
Sent from my ASUS Transformer Infinity TF700 running Android JB (rooted) via Tapatalk
iostat and top are standard unix utilities. They would only be useful if run on the phone so I must presume andriod has versions. A bit of 'googling' and htere appears to be a developer's kit that includes stuff like iostat. If hte switches are the norm then something like "iostat -x 2" will produce nice output of performance of each 'disk'. top is a tool that shows cpu usage.
-
I've not done any developing for andriod (maybe I should bite hte bullet?) so have never tried to use adb or similar but i've done a bit of system development on linux (though I very rarely muck with the kernel; i prefer to work one layer above the kernel).
johnlgalt said:
I'll need a bit more specifics - I know adb well enough and can shell, but these other ... executables you're mentioning are new to me.
Click to expand...
Click to collapse
If you haven't done it yet, install BusyBox on your TF700. Then just open one or more command windows on your PC, run adb shell in each, and run "iostat 1" in one window, "top" in another, and maybe also adb logcat in yet another window.
That gives you up-to-date statistics about I/O and processes which currently use CPU time. Then try to use your tablet normally, and when it lags, watch the output on your PC if you see a big number of writes or a process eating CPU.
But don't forget to enjoy your vacation.
_that said:
If you haven't done it yet, install BusyBox on your TF700. Then just open one or more command windows on your PC, run adb shell in each, and run "iostat 1" in one window, "top" in another, and maybe also adb logcat in yet another window.
That gives you up-to-date statistics about I/O and processes which currently use CPU time. Then try to use your tablet normally, and when it lags, watch the output on your PC if you see a big number of writes or a process eating CPU.
But don't forget to enjoy your vacation.
Click to expand...
Click to collapse
Awesome. Busybox already installed here, so this should be easy enough.
And I never forget to enjoy ... anything. lol
Sent from my ASUS Transformer Infinity TF700 running Android JB (rooted) via Tapatalk
_that said:
Good question. It's time to find out.
Arm yourself with multiple adb shells and watch the output of iostat, top, free, or whatever else you can think of that displays interesting metrics. Then do something that causes lag and see if you notice a specific pattern.
(I am currently away from my main PC, and the SSD in my laptop decided yesterday it no longer wants to read ntkrnlpa.exe - so no adb for me right now)
Click to expand...
Click to collapse
hey fellas, have you seen chainfire's app : PerfMon
http://www.xda-developers.com/android/perfmon-floats-your-devices-performance-on-screen/
real time stats including io reads/writes to both mmcblk0/mmcblk1... :good:
ps: i have always loved "android status" aswell ... oldy but a goody
https://play.google.com/store/apps/details?id=com.AndroidStatus&hl=en
Related
The lovely thing about having a Linux Kernel is that we can do a lot to optimize it.
I figured it would be a great idea to set up a thread where we can bring all these optimizations into one place.
Mind you, I'm no expert by any means...
For my (possibly useless) contribution:
When we compile the kernel to the G1, do we compile it with the general Arm eabi? If so, is that made for ALL ARM cpu's? We have an ARM6 in our G1's. If we set it up to optimize to ARM6, can we set it up to use the CPSID/CPSIE instruction instead of the SWP instruction? Are the drivers open source? Can we recompile them to do the same also? To learn more about why, read this:
http://forum.xda-developers.com/showthread.php?t=516223
That's where I got the idea from.
SWP is a deprecated opcode in armv6 that decreases performance due to the way it locks the bus.
Click to expand...
Click to collapse
Anyhow, whatever you guys post here, I will add to this post. Also, to the people to compile the kernels, can you answer my questions?
answers to some of your questions.
hi i usually don't post here since i am not a developer but in this case i think i can answer some of your questions (since i sometime make custom kernels for my laptop). kernel optimazation is used to removed excessive drivers and services from the kernel that you don't need that slows down your computer or in this case phone. i believe htc already does this when they configured android for the g1. most cell phone manufactures already do this to ensure that there products processor use energry efficiently and and run as smoothly as possible.
When we compile the kernel to the G1, do we compile it with the general Arm eabi? If so, is that made for ALL ARM cpu's? We have an ARM6 in our G1's
Click to expand...
Click to collapse
yes, arm eabi is made for all general arm cpu's i believe you can complie it for arm 6 specifically though. how do you know that htc hasn't already optimize the kernel for that specific processor? also if they didn't you wouldn't really see any noticible speed improvements by compliling the kernel for this specific processor.
Are the drivers open source?
Click to expand...
Click to collapse
no, futhermore they don't offer the drivers for the g1 except execpt for the usb driver so your computer can recognise the g1 as mass storage device.
If we set it up to optimize to ARM6, can we set it up to use the CPSID/CPSIE instruction instead of the SWP instruction?
Click to expand...
Click to collapse
i don't know sorry. thats all i know i'm really not a kernel, coding expert i hope this helps in your task.
bananajama said:
no, futhermore they don't offer the drivers for the g1 except execpt for the usb driver so your computer can recognise the g1 as mass storage device.
Click to expand...
Click to collapse
I think you meant to say "ADB interface" instead of "mass storage device."
t1n0m3n said:
I think you meant to say "ADB interface" instead of "mass storage device."
Click to expand...
Click to collapse
The system type is set to "Quaalcom MSM", so I would imagine that it's optimizing for arm6l.
cyanogen said:
The system type is set to "Quaalcom MSM", so I would imagine that it's optimizing for arm6l.
Click to expand...
Click to collapse
Sounds like it. Well, other than that, are there any other obtimizations anyone else can think of?
there are few things in linux that you can play with to see if you get any performance increase. It's mainly in memory management. run ls on /proc/sys/vm. you can play with the page cache but I doubt that you'll get much perf increase from it since, since most of the things we can play with are for write back cache. If we have access to the dalvikvm we may be able to do more optimization. The one thing that I've always wanted to be able to do is to pin Home in memory, and not allow garbage collector to kill it, so when we exit out of memory intensive apps, like browser, gallery, etc, we do not have to wait for Home to reload. If we have more control over garbage collection we may be able to do more, but I don't know much about the dalvikvm at all.
taking a quick look at the vm. The only nob that may have any effect on android may be vfs_cache_pressure. theoretically setting to 200 would push fs cache out quicker and give more memory to the vm. default is set to 100. I set it to 200 and 300 but didn't notice any difference.
knaries2000 said:
there are few things in linux that you can play with to see if you get any performance increase. It's mainly in memory management. run ls on /proc/sys/vm. you can play with the page cache but I doubt that you'll get much perf increase from it since, since most of the things we can play with are for write back cache. If we have access to the dalvikvm we may be able to do more optimization. The one thing that I've always wanted to be able to do is to pin Home in memory, and not allow garbage collector to kill it, so when we exit out of memory intensive apps, like browser, gallery, etc, we do not have to wait for Home to reload. If we have more control over garbage collection we may be able to do more, but I don't know much about the dalvikvm at all.
Click to expand...
Click to collapse
dxtop, which is a home replacement, does exactly that. It keeps itself in memory so going back to it is much faster than the default home application. And in low memory situations, it tries to free up as much resources as possible while still staying in memory.
I've seen it in threads that the "I/O" is a problem on the tf700.
What does that mean? I don't know what it is :silly:
ap3604 said:
I've seen it in threads that the "I/O" is a problem on the tf700.
What does that mean? I don't know what it is :silly:
Click to expand...
Click to collapse
http://en.wikipedia.org/wiki/Input/output
To add just a bit of context to the rather unfriendly and a bit too concise a reply above, the TF700 -- as all other Transformer edition tablets -- suffer from lags and hangups when a disk-intensive task is run concurrently with some other task (for example when installing or updating an app in the background and browsing the web or watching a (high-resolution) video at the same time) or when transferring large amounts of data to or from both internal and external memory (like that video you wanted watch while letting your apps update in the background ). Note that the term 'disk-intensive' is a relative one, since it also happens with operations so limited that it is hard to believe the hardware would be overwhelmed to any significant degree.
I was able to see this easily last night installing large apps and try to use the play st ore while downloading. Never had this on my og transformer.
Otherwise this is a beautiful tablet
MartyHulskemper nails the description, so I am listing some specific examples.
1. Installing applications stalls other action/task
Presumably, installing application actively access your flash drive and this basically freezes your system temporary even it is non-intensive application such as simply non-flash based site browsing.
2. Downloading large file stalls other action/task
Just as #1, but again this is writing/accessing your flash drive.
3. Copy/Write from PC to Tablet by USB
Small files flies. Big files inconsistently but relatively frequently stops/freezes. Presumably some sort of issue from writing to flash disk.
4. Slower PDF opening (I am speculating this)
Compared to my former system, which was dual core, opening large PDF is much slower and almost consistently gives me "No response" Error. This I am blaming on the reading from flash drive is somehow the issue.
So You will encounter the problems here and there as I/O is pretty much used everywhere.
I have only been an Android user for a couple of months, but I've been a Linux user and software developer for almost 20 years so this might be a strange question; Is it normal to put up with so many random application crashes on this platform? I am not used to such instability with Linux except in the rare case when I have introduced a bug in some kernel driver I was developing.
In addition to force close messages and mainstream applications just disappearing with no message, this family of tablets or perhaps it is the Tegra, seem to have more than the normal problems running Linux distros via chroot.
I started with a TF300 and returned it after 30 days in part because I suspected flaky hardware was to blame for the application crashes. Now I see about the same behavior with the TF700.
It has already been reported that Unity and Firefox don't work in Ubuntu 12.04 and no one seems to have any idea why. In the process of investigating this, while building a debug version of Firefox inside a Ubuntu 12.04 chroot, I encountered several non-reproducible bus errors with gcc which it reported as possible hardware or kernel errors. Restarting the make succeeded in building that object, only to fail with another random signal 7 later in another part of the build. So I switched to a Debian image and found even stranger results with processes hanging randomly (ps shows they are sleeping in one of two places in the kernel).
I have also noticed that Ubuntu process such as the vnc server just dissapear sometimes. I would suspect Android of killing it thinking it was "managing" resource use, but given the other issues, I suspect it just encountered a random bus error or segfault. If this wasn't my second sample and if others hadn't reported problems with linux installs on the Tegra, I would assume I had a bad processor.
These are not the normal symptoms of application errors. So my question is: Do we have a nasty kernel bug which is causing these random crashes and hangs? Is it a hardware problem? Or are the Android application crashes typical and the chroot Linux environment behaviors caused by some incompatability between the generic ARM builds and our Tegra architecture or perhaps some processor errata?
I have searched the forums for clues but even though the Tegra and the Transformer families have been around for a little while, I can't find any answers.
Thanks,
--Brad
You definitely get much more of this than on a stable Linux distro (although I find X-Window generally unstable as compared to other parts of the system). I have used many Android devices and it seems both build/version- and device-specific, some of them had a lot of FCs, some of them almost none. Then there come many apps with a really bad code. It should be better from the JB onwards and current code control under Android.
I think so far the Infinity is on the worse side of this, but I'm not sure what to blame, some say Tegra, some say firmware. I really hate GMail app crashing (newest app / newest firmware), I feel it's just ridiculous.
I'm not sure how deep debugging is going to get you under Android (wouldn't even want to guess ;>). If you really want to know, I guess you'll have to find out by yourself. For now, I don't think the Infinity is particularly stable, but, having sad that, I believe it's getting better, as I don't experience more random reboots under .26 firmware now, my uptime is only a few days now, but just because my testing of some custom tweaks in /system/
I havent really experienced any of those issues running a chrooted debian. Perhaps your setup is a little too heavy ram wise? Try a lighter window manager like LXDE or fluxbox. Alternatively, perhaps you're running into the IO issues that seem to plague the Tegra 3 transformers.
Jotokun said:
I havent really experienced any of those issues running a chrooted debian. Perhaps your setup is a little too heavy ram wise? Try a lighter window manager like LXDE or fluxbox. Alternatively, perhaps you're running into the IO issues that seem to plague the Tegra 3 transformers.
Click to expand...
Click to collapse
I am already running LXDE which I installed on the large Ubuntu image from the complete linux installer project and I intentionally avoided doing anything else while I was building. The build slowed things down to the point that the tablet was not very fun to use anyway. Have you tried building any large programs? Other than an occasional mysterious exit of the VNC server, that's where I started seeing most of the nasty random bus errors. Unless someone knows of a reason low memory could cause bus errors, I don't think the slow I/O would be related. Though I suppose slow I/O could cause low memory as ram gets filled up with dirty buffers. But the kernel will start to put processes to sleep when it can't find a free page to satisfy an allocation and the writes should catch up so I don't expect allocations would actually fail due to slow I/O. I do wish I could enable swap without replacing the boot loader. And I wish I could replace the boot loader without voiding my warranty.
BTW, another irritation on this tablet is the huge number of messages the kernel is spewing out constantly about starting and stopping processors and other power management and routine events. There could be an interesting message in the kernel logs related to the bus errors but I would never see it in dmesg because of the noise which quickly flushes anything else out of the circular buffer. That fact that ASUS has not taken these debug messages back out of the kernel makes it feel like it is still in development.
Has anyone else tried to build anything large under Ubuntu chroot? BTW, Firefox is so large, I allocated another 4G file system just to put the debian source in so I could run dpkg-buildpackage without filling up the file system. It looks like I could have grown my image beyond 4G. I didn't realize until just now that sdcard wasn't a fat32 file system. Or I suppose I could reformat my microSD as ext3 and move my chroot work there.
I had whole servers running under FreeBSD's jails years ago, I think it is much better than chroot.
d14b0ll0s said:
I had whole servers running under FreeBSD's jails years ago, I think it is much better than chroot.
Click to expand...
Click to collapse
That may be, at least in the case of multi-user systems where resource contention is a real problem. But in general there is no technical reason I can think of that chroot sandboxes should be unstable. The API which the kernel presents to the user level is very stable, even across major differences in kernel versions. I use linux chroot sandboxes all the time for my job and they are very stable and useful. I find that a library version mismatch (which chroot avoids) is far more likely to cause trouble than an older or newer kernel. There is something else going on here. Other ICS based tablets are able to run these chroot images with no trouble.
--Brad
An update in case anyone is interested:
I haven't learned anything about the tegra specific issues with chroot, but I do think I understand where at least half of the random android application crashes I experience are coming from.
I have been running dmesg after any android application crashes and I noticed that in over half of the cases, the kernel oops at the end of this post was reported. The oops report indicates that the nvidia driver was attempting to allocate a 64K block of physical memory. Examining nvhost_job.c in the kernel source makes it clear that the nvidia driver is poorly written with respect to dynamic allocation of large blocks of physical memory in order to satisfy dynamic application gl operations. A bit of research turned up that this bug has been reported previously way back in March on transformerforums.com. I'm not sure why it seems to have never been discussed here and I'm not sure why it has taken ASUS and Nvidia so long to fix it.
I believe this rather nasty and stupid bug explains many of the android application crashes I and others have seen, including google play, google maps (this one tends to persist until you reboot), various vnc viewers, etc. Note that this bug is more likely to be triggered the longer we go without a reboot. And stressing the system with respect to memory use, for example, by performing lots of output to the transformer's slow storage, or running lots of programs inside a chroot triggers the bug sooner.
The good news is I checked the recently available TF300 Jelly Bean kernel source on the ASUS site and was happy to see that the driver has been reworked to use virtual memory for this purpose which should solve this class of application crashes. I assume the same fix will be in JB for the TF700 when it is released.
I wish the root cause of the other Tegra specific problems I see inside the Ubuntu chroot including the compiler bus errors were as easy to debug.
--Brad
<4>[162943.445514] ogle.android.gm: page allocation failure. order:4, mode:0xd0
<4>[162943.445656] [<c004f4d0>] (unwind_backtrace+0x0/0x12c) from [<c00e86e4>] (__alloc_pages_nodemask+0x5f4/0x658)
<4>[162943.445778] [<c00e86e4>] (__alloc_pages_nodemask+0x5f4/0x658) from [<c010cddc>] (cache_alloc_refill+0x2c0/0x52c)
<4>[162943.445915] [<c010cddc>] (cache_alloc_refill+0x2c0/0x52c) from [<c010d0e0>] (__kmalloc+0x98/0xe0)
<4>[162943.446031] [<c010d0e0>] (__kmalloc+0x98/0xe0) from [<c024a874>] (nvhost_job_realloc+0x4c/0x134)
<4>[162943.446221] [<c024a874>] (nvhost_job_realloc+0x4c/0x134) from [<c024b494>] (set_submit+0x58/0x90)
<4>[162943.446336] [<c024b494>] (set_submit+0x58/0x90) from [<c024b714>] (nvhost_channelctl+0x248/0x44c)
<4>[162943.446406] [<c024b714>] (nvhost_channelctl+0x248/0x44c) from [<c011efb8>] (do_vfs_ioctl+0x500/0x57c)
<4>[162943.446544] [<c011efb8>] (do_vfs_ioctl+0x500/0x57c) from [<c011f068>] (sys_ioctl+0x34/0x54)
<4>[162943.446665] [<c011f068>] (sys_ioctl+0x34/0x54) from [<c00495c0>] (ret_fast_syscall+0x0/0x30)
<4>[162943.446801] Mem-info:
<4>[162943.446858] Normal per-cpu:
<4>[162943.446915] CPU 0: hi: 186, btch: 31 usd: 1
<4>[162943.447036] HighMem per-cpu:
<4>[162943.447094] CPU 0: hi: 186, btch: 31 usd: 0
<4>[162943.447180] active_anon:91412 inactive_anon:172 isolated_anon:0
<4>[162943.447184] active_file:31694 inactive_file:44876 isolated_file:32
<4>[162943.447187] unevictable:227 dirty:8 writeback:0 unstable:0
<4>[162943.447190] free:16204 slab_reclaimable:2875 slab_unreclaimable:3047
<4>[162943.447193] mapped:18781 shmem:208 pagetables:2670 bounce:0
<4>[162943.447635] Normal free:62760kB min:3224kB low:4028kB high:4836kB active_anon:172696kB inactive_anon:112kB active_file:82056kB inactive_file:109704kB unevictable:0kB isolated(anon):0kB isolated(file):128kB present:650240kB mlocked:0kB dirty:32kB writeback:0kB mapped:37376kB shmem:180kB slab_reclaimable:11500kB slab_unreclaimable:12188kB kernel_stack:7312kB pagetables:10680kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
<4>[162943.448281] lowmem_reserve[]: 0 2880 2880
<4>[162943.448608] HighMem free:2056kB min:360kB low:816kB high:1272kB active_anon:192952kB inactive_anon:576kB active_file:44720kB inactive_file:69800kB unevictable:908kB isolated(anon):0kB isolated(file):0kB present:368656kB mlocked:0kB dirty:0kB writeback:0kB mapped:37748kB shmem:652kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
<4>[162943.450980] lowmem_reserve[]: 0 0 0
<4>[162943.451323] Normal: 3378*4kB 4302*8kB 901*16kB 40*32kB 2*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 63752kB
<4>[162943.452059] HighMem: 256*4kB 35*8kB 27*16kB 6*32kB 0*64kB 1*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 2056kB
<4>[162943.452864] 76613 total pagecache pages
<4>[162943.452924] 0 pages in swap cache
<4>[162943.452983] Swap cache stats: add 0, delete 0, find 0/0
<4>[162943.453091] Free swap = 0kB
<4>[162943.453149] Total swap = 0kB
<4>[162943.498866] 261632 pages of RAM
<4>[162943.498982] 17680 free pages
<4>[162943.499041] 11846 reserved pages
<4>[162943.499118] 5922 slab pages
<4>[162943.500755] 258372 pages shared
<4>[162943.500869] 0 pages swap cached
After I do a fresh install of cromi on my tablet, it's just excellent, fluid and smooth. After a while, the performance seems to detoriate. It has done so for about every version I tried and the same goes for my phone (An i9300 running slimkat). So my question is this: What makes an android device inherently slower? Is there a way to see what apps may slow down the performance?
vonVaffel said:
After I do a fresh install of cromi on my tablet, it's just excellent, fluid and smooth. After a while, the performance seems to detoriate. It has done so for about every version I tried and the same goes for my phone (An i9300 running slimkat). So my question is this: What makes an android device inherently slower? Is there a way to see what apps may slow down the performance?
Click to expand...
Click to collapse
That is a very good question...:good: I have the same question but I can not find a solid answer for it. I hope that some developers or experts can give us a good definition of it...
This is what I know but I may be totally off and wrong, haha..
When you first install the new ROM, all your partitions are new and clean. When you write something to your data partition, it is most of the case, it just writes data to a clean blocks without erasing the blocks. After a while, most of your blocks are dirty even though they are unused or available for writing. This is the part that users see the degradation. When a new data is writing to the available and dirty blocks, first the kernel has to erase the block before writing to it. The erase process takes a lot longer than the write process according to my research...:crying: On our tf700, writing to the internal sd or mmc is very slow already. On top of that, the erasing process has to be done before writing the new data to your internal sd. If you do the math, the performance of the writing will degrade more than twice comparing the new installation..:crying: I believe that google noticed this issue so they implemented the fsTRIM on the newer kernel source to tackle this problem..:good:
However, when you are using the fsTRIM, you have to sacrifice some slightly performance loss and you don't notice performance degradation over time.. During the normal usage, I can not tell the differences if the fsTRIM is on or off but I did see the small performance loss with a bench test.. In short, I know both _that and hund's kernel support the fsTRIM but it is disable as a default. You can try to enable it to see if it is solving your degraded problem....Good luck...:fingers-crossed:
Another method is to use the lagfix manually once a week or more frequently...
Usually I reboot to recovery, wipe cache (don't need to do dalvik), reboot back to ROM and everything is quick again.
I don't know why this works though.
sbdags said:
Usually I reboot to recovery, wipe cache (don't need to do dalvik), reboot back to ROM and everything is quick again.
I don't know why this works though.
Click to expand...
Click to collapse
Thanks sbdags for the information...
LetMeKnow said:
This is what I know but I may be totally off and wrong, haha..
Click to expand...
Click to collapse
Mostly correct.
LetMeKnow said:
When a new data is writing to the available and dirty blocks, first the kernel has to erase the block before writing to it.
Click to expand...
Click to collapse
It's the controller in the eMMC that does that. The peculiarities of flash memory - no way to directly overwrite data, need to erase in large blocks before writing, can't write to the same location too often or it wears out - are all hidden by a small (and not very smart, in our case) controller. The kernel sees a block device that it can use like a mechanical hard drive.
LetMeKnow said:
Another method is to use the lagfix manually once a week or more frequently...
Click to expand...
Click to collapse
This depends how much data is written and how much space is free. If you have 10 GB free and you run lagfix once, you won't benefit from running it again until after 10 GB have been written to flash. Random writes cost more than their real size (see above, overwrites must be simulated by rewriting larger blocks), sequential writes translate to about their actual size written to flash.
_that said:
Mostly correct.
It's the controller in the eMMC that does that. The peculiarities of flash memory - no way to directly overwrite data, need to erase in large blocks before writing, can't write to the same location too often or it wears out - are all hidden by a small (and not very smart, in our case) controller. The kernel sees a block device that it can use like a mechanical hard drive.
This depends how much data is written and how much space is free. If you have 10 GB free and you run lagfix once, you won't benefit from running it again until after 10 GB have been written to flash. Random writes cost more than their real size (see above, overwrites must be simulated by rewriting larger blocks), sequential writes translate to about their actual size written to flash.
Click to expand...
Click to collapse
Thanks _that for sharing the information and time...:good:
I take the mostly correct and hate the least incorrect....:crying: Every time I talk to you. It seems like there is a language barrier. Oh yeah, it is called an Android language, hehe... I will loose a few days researching and trying to understand what you are saying...:silly: However, I feel like that I understand android a bit more in the end and thanks for that....
Now it is time for me to bang my head on the keyboard for the next few days...:crying:
Thanks for the insightful information guys, you are frickin awesome! . I thought the lagfix app was removed from CROMI, since the trim function was no longer needed after 4.2. I might be wrong about this, but in any case I have LagFix premium which can trim partitions on a schedule, and I take it that it doesn't do any harm at least?
vonVaffel said:
Thanks for the insightful information guys, you are frickin awesome! . I thought the lagfix app was removed from CROMI, since the trim function was no longer needed after 4.2. I might be wrong about this, but in any case I have LagFix premium which can trim partitions on a schedule, and I take it that it doesn't do any harm at least?
Click to expand...
Click to collapse
I personally like the "discard" mounting option on Cromi x.. It is just my personal preference...:laugh: I don't recall that the lagfix was a problem for me but I heard some issued stories about it but could not remember now, sorry...
vonVaffel said:
Thanks for the insightful information guys, you are frickin awesome! . I thought the lagfix app was removed from CROMI, since the trim function was no longer needed after 4.2. I might be wrong about this, but in any case I have LagFix premium which can trim partitions on a schedule, and I take it that it doesn't do any harm at least?
Click to expand...
Click to collapse
CROMI is based off ASUS' stock firmware, hence it is still Android 4.2.1 (and will likely stay that way forever since ASUS does not update the tf700 anymore). As TRIM is only available in Android 4.3 onward, Lagfix is still a relevant. As far as I know, some people reported data corruption from using Lagfix, but I personally haven't had any issue. Your mileage may vary though.
As for performance degradation, I am also quite interested in knowing why. One of the key strength of Linux over Windows is that Linux does not have this performance degradation over time and most Linux users will happily attest to this statement. Apparently, Google has somehow removed that strength when they made Android. Many people who choose iOS over Android will also cite this performance degradation as a factor since iOS does not suffer from this problem as well, if at all. At this point, I am just going to blame Dalvik VM for all this inefficiency. If you look at Windows Phone 8 (made by the same company that brought you Windows) and iOS, both run native machine code instead of a virtual machine and they don't have any drop in performance over time. Practically, a HTC HD7 with WP7 can still compete with current Android handsets in terms of UI smoothness and exhibit no stuttering nonewhatsoever, except when you started using intensive apps, but that is definitely a hardware limitation.
huy_lonewolf said:
As TRIM is only available in Android 4.3 onward, Lagfix is still a relevant.
Click to expand...
Click to collapse
"Trim" is a kernel feature and is activated by using the ext4 mount option "discard", which has been in the kernel since 2010.
Expanding a bit on the issue at hand, I'm curious about two types of apps:
First one is twilight. It's much like the f.lux or redshift program for PCs making the screen red at nighttime, so that falling asleep is supposedly easier. Now I enjoy using this on any type of screen I'm in front of after dark, but the downside to this is that it makes both my tablet and phone really laggy. My phone (i9300) isn't as affected by the performance as the tf700 is, but I wonder why this sort of app slows the device down?
Second app is SwiftKey. I love this keyboard app for its functionality and its predictions. However not being a native English speaker, I also write a lot of Norwegian so I have two word lists installed. My issue is that the keyboard seems slow and sluggish in its response, and sometimes it takes forever to actually write something down. Is this related to using two dictionares instead of one? I really love this app and would like to keep on using it, as no other keyboard seems as good to me.
vonVaffel said:
Expanding a bit on the issue at hand, I'm curious about two types of apps:
First one is twilight. It's much like the f.lux or redshift program for PCs making the screen red at nighttime, so that falling asleep is supposedly easier. Now I enjoy using this on any type of screen I'm in front of after dark, but the downside to this is that it makes both my tablet and phone really laggy. My phone (i9300) isn't as affected by the performance as the tf700 is, but I wonder why this sort of app slows the device down?
Second app is SwiftKey. I love this keyboard app for its functionality and its predictions. However not being a native English speaker, I also write a lot of Norwegian so I have two word lists installed. My issue is that the keyboard seems slow and sluggish in its response, and sometimes it takes forever to actually write something down. Is this related to using two dictionares instead of one? I really love this app and would like to keep on using it, as no other keyboard seems as good to me.
Click to expand...
Click to collapse
I also use f.lux on all our laptops. Never heard of twillight. I highly recommend and have used Lux Dash (location based sunset setting etc) for what seems like forever on Kindle Fire, Note, Note 2 and TF700 and it can even dim down to pretty much all black if you want it to. I never experienced any slow-down because of it on the Infinity.
Just last week I read about two apps that slow down the posters Infinity and one of them was Swiftkey and there was no mention of your dual language setting and I suspect it's not a dual language issue. I've used Danish & English (and briefly Spanish for Duolingo app so 3 at the same time) and also noticed it being very unresponsive, but haven't noticed any diffence with 1, 2, or 3 languages. Now it solely resides on my Note 2. Should be easy to test though, just by disabling one language and see if it makes a difference.
I can't remember what the other app was though. It was some post or article about lowering RAM usage by, among other things, using Titanium to change certain downloadable system apps (Gmail, Dropbox etc) into user apps and then using Greenify. Hopefully Greenify will work on this new Cromi-KK ROM I just installed, but that's on tomorrow's To Do List. Note: Greenify can only do system apps (paid version) with Xposed installer and Xposed doesn't work with KitKat.
Hope that was somewhat useful and not a complete waste of your time :silly:
Not sure if I need to create a new thread, or post here, but I'm at a loss. I feel like I've wasted a ton of money on this thing. I bought the TF700 over the Galaxy 10.1 thinking it had better specs and was going to be a great product from ASUS. First problem I had was "phantom touches" and had to send it in for repair. Now it's utterly useless. It SUPER slow, so slow that I'd rather throw it in the trash than deal with it. I've tried Clean Master, but it never seemed to help performance. I installed CROMBI-kk and it's still has poor performance. I've set the wallpaper to black (none), removed all widgets, and installed maybe 2 apps so far. I also tried LagFix but it says it doesn't have permission to modify the directories (or something like that). I've ensured that Root is enabled under Developer Options.
My old Incredible (v1) runs better than this. I really don't know what to do. It's very frustrating. I even wasted the money on the keyboard attachment but in combination with the lag, I can't even bear to use it. I downloaded 2048 and swipes are slow, and once the tiles move, sometimes it takes a couple of seconds for the numbers to merge.
Is there ANYTHING I can do? I've looked through the suggestions. Am I missing something? Does EVERYONE have this problem with their TF700? I wrote ASUS about it and basically said "since you unlocked the device, we would have to replace the mainboard for $300 (parts + labor) in order to undergo any out-of-warranty diagnostics." The only reason I unlocked it was because I've heard that the performance problems were due to the ASUS software, so I thought installing a custom ROM would be the answer to my problem.
Any idea if this is a hardware issue, or something that can be fixed in the software?
briandichiara said:
Not sure if I need to create a new thread, or post here, but I'm at a loss. I feel like I've wasted a ton of money on this thing. I bought the TF700 over the Galaxy 10.1 thinking it had better specs and was going to be a great product from ASUS. First problem I had was "phantom touches" and had to send it in for repair. Now it's utterly useless. It SUPER slow, so slow that I'd rather throw it in the trash than deal with it. I've tried Clean Master, but it never seemed to help performance. I installed CROMBI-kk and it's still has poor performance. I've set the wallpaper to black (none), removed all widgets, and installed maybe 2 apps so far. I also tried LagFix but it says it doesn't have permission to modify the directories (or something like that). I've ensured that Root is enabled under Developer Options.
My old Incredible (v1) runs better than this. I really don't know what to do. It's very frustrating. I even wasted the money on the keyboard attachment but in combination with the lag, I can't even bear to use it. I downloaded 2048 and swipes are slow, and once the tiles move, sometimes it takes a couple of seconds for the numbers to merge.
Is there ANYTHING I can do? I've looked through the suggestions. Am I missing something? Does EVERYONE have this problem with their TF700? I wrote ASUS about it and basically said "since you unlocked the device, we would have to replace the mainboard for $300 (parts + labor) in order to undergo any out-of-warranty diagnostics." The only reason I unlocked it was because I've heard that the performance problems were due to the ASUS software, so I thought installing a custom ROM would be the answer to my problem.
Any idea if this is a hardware issue, or something that can be fixed in the software?
Click to expand...
Click to collapse
Something is not right mate.
Confirm what boot loader you are on please, which recovery and how you updated the ROM then we can get you setup so experience your tab like never before
sbdags said:
Something is not right mate.
Confirm what boot loader you are on please, which recovery and how you updated the ROM then we can get you setup so experience your tab like never before
Click to expand...
Click to collapse
I followed the instructions in the thread, using twrp-2.6.3-that3_Signed.zip and cm-11.0-20140322-CROMBikk4.4.2-tf700t_Signed.zip. I had already unlocked it a while back with the intention of installing a ROM but never did until yesterday, But I had TWRP 2.3.3.3 installed.
I booted up the tablet, plugged it into the computer, copied over TWRP 2.6.3 (zip) and CROMBI-kk (zip) onto internal storage. Powered down and powered back in into RCK (recovery). First thing I did was an advanced wipe, wiping everything except for the SD card and internal storage. Then installed TWRP from the zip on the storage. Rebooted Recovery. Did the same advanced wipe (x2), then installed the CROMBI zip from within recovery, pretty much leaving all the defaults for the install except for I chose Google Experience Launcher (not sure why, never tried it I guess). That's pretty much it. It installed fine, didn't seem to have any errors or anything odd. Booted up fine, went through the setup process on first boot. Setup 1 Google Account, and installed a few apps (mainly just Chrome and 2048). Other apps installed by ROM were: AdAway, Google+ (for auto-backup), Maps, Hangouts, and I installed SwiftKey. Most everything else seems to be stock.
As far as bootloader, not really sure. When I do the volume-down+power boot, I see Key driver not found.. Android cardhu-user bootloader (1.00 e) released by "US_epad-10.6.1.14.8-20130514" A03. I can get into Terminal Command from TWRP so if I need to run any commands to find out any information, let me know.
Thanks for your response and willingness to help!
briandichiara said:
I followed the instructions in the thread, using twrp-2.6.3-that3_Signed.zip and cm-11.0-20140322-CROMBikk4.4.2-tf700t_Signed.zip. I had already unlocked it a while back with the intention of installing a ROM but never did until yesterday, But I had TWRP 2.3.3.3 installed.
I booted up the tablet, plugged it into the computer, copied over TWRP 2.6.3 (zip) and CROMBI-kk (zip) onto internal storage. Powered down and powered back in into RCK (recovery). First thing I did was an advanced wipe, wiping everything except for the SD card and internal storage. Then installed TWRP from the zip on the storage. Rebooted Recovery. Did the same advanced wipe (x2), then installed the CROMBI zip from within recovery, pretty much leaving all the defaults for the install except for I chose Google Experience Launcher (not sure why, never tried it I guess). That's pretty much it. It installed fine, didn't seem to have any errors or anything odd. Booted up fine, went through the setup process on first boot. Setup 1 Google Account, and installed a few apps (mainly just Chrome and 2048). Other apps installed by ROM were: AdAway, Google+ (for auto-backup), Maps, Hangouts, and I installed SwiftKey. Most everything else seems to be stock.
As far as bootloader, not really sure. When I do the volume-down+power boot, I see Key driver not found.. Android cardhu-user bootloader (1.00 e) released by "US_epad-10.6.1.14.8-20130514" A03. I can get into Terminal Command from TWRP so if I need to run any commands to find out any information, let me know.
Thanks for your response and willingness to help!
Click to expand...
Click to collapse
OK I don't quite understand your advanced wipe decisions. Also what is 2048?
You need to make sure you are at least wiping /data. It may be worth loading CROMBi-kk to microsd and doing a full format on internal which will do data and the whole internal sd - it'll take about 90 mins+ so nmake sure you have enough juice.
The will eliminate any remnants and left overs.
Your bootloader *should* be fine although it is slightly old as the latest one is 10.6.1.14.10 but I don't think that causes any issues. Also make sure you choose _that's kernel in the installer and it doesn't hurt to disable journaling, disable fsync and enable the 2 GPU options.
Finally after it boots go to settings, about tablet and click the build number 7 times to enable developer settings. Then go into developer settings, enable power menu, root and set your 3 animation settings to 0.5x or zero. Last but not least change the runtime from dalvik to art and then let it reboot.
Let it settle. How does it feel now?
sbdags said:
OK I don't quite understand your advanced wipe decisions. Also what is 2048?
Click to expand...
Click to collapse
In the past, I've read to do multiple wipes, but the items I'm wiping should be all except the SD_CARD and Internal Storage. 2048 is a little number game: http://gabrielecirulli.github.io/2048/ (https://play.google.com/store/apps/details?id=com.digiplex.game)
sbdags said:
You need to make sure you are at least wiping /data. It may be worth loading CROMBi-kk to microsd and doing a full format on internal which will do data and the whole internal sd - it'll take about 90 mins+ so nmake sure you have enough juice.
Click to expand...
Click to collapse
When I get some free time, I'll come back and give this a shot. Thanks for all your help.
sbdags said:
Your bootloader *should* be fine although it is slightly old as the latest one is 10.6.1.14.10 but I don't think that causes any issues. Also make sure you choose _that's kernel in the installer and it doesn't hurt to disable journaling, disable fsync and enable the 2 GPU options.
Click to expand...
Click to collapse
I'll make a note of this as well when I go back through this. I'm not sure where I had the choice of kernel in the installer, but I'll make sure I choose _that's. I don't know what those other options are, but again, will keep an eye out for them.
sbdags said:
Finally after it boots go to settings, about tablet and click the build number 7 times to enable developer settings. Then go into developer settings, enable power menu, root and set your 3 animation settings to 0.5x or zero. Last but not least change the runtime from dalvik to art and then let it reboot.
Click to expand...
Click to collapse
Thank you for all this information. When I get some time, I'll give these steps a shot and hopefully be much happier with my tablet. Thanks again!
Fire are so cheap, that's great,but it's so slow even for normal task.
Long time ago,I have found the performance Bottleneck
Of fire is RAM,not CPU,at least for daily normal use like browser web.when I open more than 3 app like chrome videos music play store,the fire become so slow even get stuck, that's really bad.so the problem is It run out of RAM.it only has 1.7G ram for hd 10 and 1.4g for hd 7 or 8. That's really small today.here is solution I found , it's amazing efficient,really make your fire usable even you run many many apps simultaneously.
One word is "swap".
Swap can make you disk storage to be used as RAM,we know disk is slower than RAM,but as I have test, it's OK,you can do it. : )
First get your fire rooted
Next download a terminal I recommend termux,a powerful tool.
Open temux,now you can run many Linux command on you ,run following command:
su
dd if=/dev/zero of=swap bs=200m count=20
mkswap swap
swapon swap
you will creat 200m*20 about 3.5G ram,also,it takes up the same amount storage,but it worth.
to check if you turn on swap run follow command:
exit
free -m
You'll see you ram status include swap
if you dont ru su before,you dont need exit command beacause you are normal user
swap make big diff experience on you fire, now try it
i can run firefox snd chrome and many app at same time at a acceptable speed.amazing!!!
you will
This is my first share on XDA,I think it's really useful, hope help you too : )
iuyals said:
Fire are so cheap, that's great,but it's so slow even for normal task.
Long time ago,I have found the performance Bottleneck
Of fire is RAM,not CPU,at least for daily normal use like browser web.when I open more than 3 app like chrome videos music play store,the fire become so slow even get stuck, that's really bad.so the problem is It run out of RAM.it only has 1.7G ram for hd 10 and 1.4g for hd 7 or 8. That's really small today.here is solution I found , it's amazing efficient,really make your fire usable even you run many many apps simultaneously.
One word is "swap".
Swap can make you disk storage to be used as RAM,we know disk is slower than RAM,but as I have test, it's OK,you can do it. : )
First get your fire rooted
Next download a terminal I recommend termux,a powerful tool.
Open temux,now you can run many Linux command on you ,run following command:
su
dd if=/dev/zero of=swap bs=200m count=20
mkswap swap
swapon swap
you will creat 200m*20 about 3.5G ram,also,it takes up the same amount storage,but it worth.
to check if you turn on swap run follow command:
exit
free -m
You'll see you ram status include swap
if you dont ru su before,you dont need exit command beacause you are normal user
swap make big diff experience on you fire, now try it
i can run firefox snd chrome and many app at same time at a acceptable speed.amazing!!!
you will
Click to expand...
Click to collapse
Yes, adding a static swap file and adjusting 'swappiness' can make a huge difference in responsiveness, especially when multitasking and after wake from extended sleep when many apps attempt to resync. The file does not need to be large and can be placed in the cache partition if desired.
My recommendations:
- 256MB static swap file
- set swappiness to 10
- leave ZRAM swap intact if present
- (optional) set ZRAM priority higher than static file to favor ZRAM storage
Also no need to use obsecure terminal commands. The free app Apps2SD easily handed swap file creation and management.
Davey126 said:
Yes, adding a static swap file and adjusting 'swappiness' can make a huge difference in responsiveness, ...
My recommendations:
- 256MB static swap file
- set swappiness to 10
- leave ZRAM swap intact if present
- (optional) set ZRAM priority higher than static file to favor ZRAM storage
Also no need to use obsecure terminal commands. The free app Apps2SD easily handed swap file creation and management.
Click to expand...
Click to collapse
Which "Apps2SD" does one download? There are quite a few apps with similar name "App2SD".
Is this the one ?
https://www.apps2sd.info/features
https://play.google.com/store/apps/...rce=Website&utm_medium=Home&utm_campaign=Home
Thank you.
Dan_firehd said:
Which "Apps2SD" does one download? There are quite a few apps with similar name "App2SD".
Is this the one ?
https://www.apps2sd.info/features
https://play.google.com/store/apps/...rce=Website&utm_medium=Home&utm_campaign=Home
Thank you.
Click to expand...
Click to collapse
Yep - that's the pup.
{interesting: name varies depending on entry point; author calls it "Apps2SD" but is posted as "App2SD" in the Play Store}
Oh, thanks so much,you introduce me zram, which a More amazing concept,as I have test,it has better performance than swap,now I change to zram,thx,it's better to my disk
its so good to share,bc i get a better one : )
Does anyone know the PROS and CONS, as far as ZRAM is concerned, between Apps2SD and RAMExpander?
See the following post about RAMExpander:
https://forum.xda-developers.com/hd8-hd10/general/best-optimization-hack-experience-t3730239
Thanks.
Dan_firehd said:
Does anyone know the PROS and CONS, as far as ZRAM is concerned, between Apps2SD and RAMExpander?
See the following post about RAMExpander:
https://forum.xda-developers.com/hd8-hd10/general/best-optimization-hack-experience-t3730239
Thanks.
Click to expand...
Click to collapse
Apples and oranges. Apps2SD is simply a tool that provides GUI for defining and managing static swap files. RAMExpander appears to do the same thing with predefined (and excessive IMO) values. ZRAM is a seperate beast that is best left alone unless one is familiar with Virtual Memory Management and the various interactions that take place between tuneables.
-- I accidentally posted in the wrong thread, sry --
Davey126 said:
Yes, adding a static swap file and adjusting 'swappiness' can make a huge difference in responsiveness, especially when multitasking and after wake from extended sleep when many apps attempt to resync. The file does not need to be large and can be placed in the cache partition if desired.
My recommendations:
- 256MB static swap file
- set swappiness to 10
- leave ZRAM swap intact if present
- (optional) set ZRAM priority higher than static file to favor ZRAM storage
Also no need to use obsecure terminal commands. The free app Apps2SD easily handed swap file creation and management.
Click to expand...
Click to collapse
Is this (attachment) ok?
Oco said:
Is this (attachment) ok?
Click to expand...
Click to collapse
That works! Don't expect miracles. Still a low resource gizmo; reading/writting to static swap is magnitudes slower than memory based zram. But it does allow the OS to swap when needed without thrashing. Setting swappiness to 10 encourages the retention of processes in memory while reducing the chance of exhusting available swap space. If that happens the device will become a complete dog due to thrashing on slow file based swap; a reboot will fix things up.
Davey126 said:
That works! Don't expect miracles. Still a low resource gizmo; reading/writting to static swap is magnitudes slower than memory based zram. But it does allow the OS to swap when needed without thrashing. Setting swappiness to 10 encourages the retention of processes in memory while reducing the chance of exhusting available swap space. If that happens the device will become a complete dog due to thrashing on slow file based swap; a reboot will fix things up.
Click to expand...
Click to collapse
Thanks, is this the same for fire 8 and fire 7?
Oco said:
Thanks, is this the same for fire 8 and fire 7?
Click to expand...
Click to collapse
Yep with caveats. Haven't messed with Fire 8 (2018) virtual memory as stock settings/performance are adequate for my current needs. Wake lag on the HD 8 is non-existent with my app portfolio which was the driver for adding a static swap file on the Fire 7. As a general rule I avoid turning knobs and dials unless there is a benefit that offsets the effort and potential side-effects.
Davey126 said:
Yep with caveats. Haven't messed with Fire 8 (2018) virtual memory as stock settings/performance are adequate for my current needs. Wake lag on the HD 8 is non-existent with my app portfolio which was the driver for adding a static swap file on the Fire 7. As a general rule I avoid turning knobs and dials unless there is a benefit that offsets the effort and potential side-effects.
Click to expand...
Click to collapse
Agreed. While I have no experience with other Fire tabs, the Fire 8 HD 2018 is way better than I expected after reading some of the threads in this forum. I have now disabled the major bloats but find no big difference in either speed or battery drain.
Hi guys. I am late to this thread, of course.
Can anyone tell me how to root the fire 7 9th gen which runs on version 7.3.1.8?
I see that the fire 7 can run way faster because of the methods above but my device can't be rooted because it seems it can't be rooted by where I looked to root it.
All Fire tablets are entry-level that aren't intended for multitasking.
AmznUser444 Dev said:
All Fire tablets are entry-level that aren't intended for multitasking.
Click to expand...
Click to collapse
I see. So you are saying that they can't be rooted? Like the version I have right now? Just wanting to change the swap.
Animate Blade said:
Hi guys. I am late to this thread, of course.
Can anyone tell me how to root the fire 7 9th gen which runs on version 7.3.1.8?
I see that the fire 7 can run way faster because of the methods above but my device can't be rooted because it seems it can't be rooted by where I looked to root it.
Click to expand...
Click to collapse
Try kingroot.
kwanbis said:
Try kingroot.
Click to expand...
Click to collapse
Does it work? Did you have experience of it? I'll see though and come back With some info on it.
Animate Blade said:
Does it work? Did you have experience of it? I'll see though and come back With some info on it.
Click to expand...
Click to collapse
I just flashed LineageOS 12.1 on my two FireHD10. The first one I had blocked the OTA updates so I was able to install TWRP following this guide:
[UNLOCK][ROOT][TWRP][UNBRICK] Fire HD 10 2017 (suez)
Read this whole guide before starting. This is for the 7th gen Fire HD10 (suez). Current version: amonet-suez-v1.1.2.zip NOTE: This process does not require you to open your device, but should something go horribly wrong, be prepared to do...
forum.xda-developers.com
But for the second one, I had forgotten to block the OTA updates so the first step which requires root was not working. I used kingroot to root it first and then followed the guide I posted above.
I did the soft brick to downgrade and then I installed LineageOS 12.1
[discontinued][ROM][unlocked][suez] Lineage-12.1 [05 MAY 2020]
Disclaimer /* * I am not responsible for bricked devices, dead SD cards, thermonuclear war, * or you getting fired because the alarm app failed. * Please do some research if you have any concerns about features included * in the products...
forum.xda-developers.com
I did it 2 or 3 days ago.