Has anyone every tried this on the z5c? what are your experiences?
the biggest bottleneck on the device is the ram (and the android system already uses a lot)
I have same question.
on my old sony i manage to do swap partition without any special kernel , just rooted and use auto app\terminal\script
ill do the same when my warranty will over
there is a zram built in to the aosp... is that the same?
AlphaDream0 said:
swap partition
Click to expand...
Click to collapse
SWAP is slow and not stable. ZRAM in this plan the better.
NeoBeum said:
there is a zram built in to the aosp... is that the same?
Click to expand...
Click to collapse
Standard ZRAM is not bad, but it has to be optimized with patches to enable LZ4 compressor and then it will be fine.
Related
Developers please help. It seems that our Nexus Ones are restricted to only 180 MB RAM as their is a bug in the kernel. Can anyone make or compile a RAMhack that can open up the extra 100-150 MB RAM. The below is an excerpt from another thread under the Nexus One - Nexus One forum here in XDA. Im wondering how much faster this thing will fly. It seems a MEMhack such as the one they used to free the 10MB for the dream might be the same approach. Apparently Google will patch this but there is no ETA on the next update.
A "memhack" kernel update in the next Nexus One OTA should give us an additional 100-150MB RAM. Who wants to try to compile a kernel that does this now?
reserved for space
flak0 said:
Developers please help. It seems that our Nexus Ones are restricted to only 180 MB RAM as their is a bug in the kernel. Can anyone make or compile a RAMhack that can open up the extra 100-150 MB RAM. The below is an excerpt from another thread under the Nexus One - Nexus One forum here in XDA. Im wondering how much faster this thing will fly. It seems a MEMhack such as the one they used to free the 10MB for the dream might be the same approach. Apparently Google will patch this but there is no ETA on the next update.
A "memhack" kernel update in the next Nexus One OTA should give us an additional 100-150MB RAM. Who wants to try to compile a kernel that does this now?
Click to expand...
Click to collapse
it's really only a matter of time on this ... once the 2.6.3x kernel is perfected for the mahimahi HW ... we'll get it. Think tank not really necessary ... as it's in the works.
~enom~
Ummmm. I thought that was the goal here:
http://forum.xda-developers.com/showthread.php?t=616383
Doubt we need the 2nd thread.
That is correct that is the goal however, until the .32 kernel is perfected is there a way to hack the current Kernel like it was done for the Dream to get the extra memory back. I am just making a suggestion. I know the only issue with the .32 kernel is the proximity sensor fails from what I have read. Can this be confirmed?
All sensors work fine with 2.6.32. Google put the sensor code in git a few days ago. I am having issues with the camera, but another person in the kernel thread said he got it working, but I can't confirm it yet.
As for the memory hack, I do not know how to do it, but the memory map and allocation are in <kernel dir>/arch/arm/mach-msm and the two files are line 959 in board-mahimahi.c and board-mahimahi.h has the memory map table breakdown.
Edit: I just got the camera working
Wont enabling that ram for program use affect the GPU(Like on the G1)?
~~Tito~~ said:
Wont enabling that ram for program use affect the GPU(Like on the G1)?
Click to expand...
Click to collapse
No, there is ram that isn't even allocated in the nexus unlike the G1. You would just move everything around and nothing would be adversely affected (in theory).
staulkor said:
No, there is ram that isn't even allocated in the nexus unlike the G1. You would just move everything around and nothing would be adversely affected (in theory).
Click to expand...
Click to collapse
Thats a bug google said would be fixed and more ram would be avail for the Nexus.
According to swetland, the only way is via the .32 kernel due to the problems caused by the 1:1 requirement. Otherwise it sounds like things go bad very quickly.
swetland said:
Roughly 220MB is available to userspace in the shipping build (ERD79).
Quite a lot of memory is dedicated to the radio firmware (41MB), dsp firmware (32MB), display surfaces (32MB), gpu (3MB), camera (8MB), a/v buffers (41MB), and dsp buffers. Much of this needs to be set aside for these specific tasks due to hardware requirements of very large physically contiguous buffers which can be difficult or impossible to obtain after boot once the physical memory space gets fragmented.
The big limitation though is that the Linux kernel needs to do a 1:1 physical:virtual map of general purpose memory used by the kernel and userspace (which excludes the special purpose stuff described above). This eats into the available kernel virtual address space, which is also needed for cross process shared memory used by the binder, etc. Run out of virtual memory and things get unhappy.
In 2.6.32, HIGHMEM support for ARM will allow us to avoid this requirement for a 1:1 mapping which will allow us to increase memory available to userspace without running the system out of virtual memory adddress space.
Click to expand...
Click to collapse
bofslime said:
According to swetland, the only way is via the .32 kernel due to the problems caused by the 1:1 requirement. Otherwise it sounds like things go bad very quickly.
Click to expand...
Click to collapse
Thanks for the details. I wasn't aware of what was causing the problem before reading this. This makes a lot of sense.
If you know, please list the advantages of having an EXT4 file system, I have searched the forums, but came up with nothing specific. I'm more concerned with the performance gains than cosmetic ones (ie, read and write access versus directory organization) but any info you have would be interesting.
i found this
clicky
but I wondered if anyone could dumb it down for a linux noobie
EDIT:
To tie this in with the Atrix Specifically, their are 2 versions of the EternityProject Kernel, one with EXT3 and one with EXT4, and I wondered if I would get performance boosts for EXT4.
OK this is going to be very simple, so a lot of people will probably quibble with what I am going to say, it is a very complex subject.
ext2 was great and fast, along came ext3, slower but the added features far outweighed the disadvantages
When ext4 come out a lot of people avoided it as "buggy" Most if not all the bugs have been removed or fixed
Ext4 adds speed to ext3 and allows for some truly massive files
So IMHO if you want rock solid ext3, but if you want a faster system with more features and a small chance of bugs then ext4
What are some of the added features?
Sent from my MB860 using Tapatalk
well this is pretty straight forward list
http://www.thegeekstuff.com/2011/05/ext2-ext3-ext4/
from that link here is a short list of ext4
Ext4 stands for fourth extended file system.
It was introduced in 2008.
Starting from Linux Kernel 2.6.19 ext4 was available.
Supports huge individual file size and overall file system size.
Maximum individual file size can be from 16 GB to 16 TB
Overall maximum ext4 file system size is 1 EB (exabyte). 1 EB = 1024 PB (petabyte). 1 PB = 1024 TB (terabyte).
Directory can contain a maximum of 64,000 subdirectories (as opposed to 32,000 in ext3)
You can also mount an existing ext3 fs as ext4 fs (without having to upgrade it).
Several other new features are introduced in ext4: multiblock allocation, delayed allocation, journal checksum. fast fsck, etc. All you need to know is that these new features have improved the performance and reliability of the filesystem when compared to ext3.
In ext4, you also have the option of turning the journaling feature “off”.
Tao_Man said:
well this is pretty straight forward list
http://www.thegeekstuff.com/2011/05/ext2-ext3-ext4/
from that link here is a short list of ext4
Click to expand...
Click to collapse
Cool stuff! What is the maximum micro SD Card size? 32 GB! I suspect that ext3 will work well enough for now.
papakilo10 said:
Cool stuff! What is the maximum micro SD Card size? 32 GB! I suspect that ext3 will work well enough for now.
Click to expand...
Click to collapse
Yes.
That exabyte, is scaryyy....
Sent from my MB860 using XDA App
Thanks, Tao_Man, for the much easier to understand link.
Tao_Man said:
Several other new features are introduced in ext4: multiblock allocation, delayed allocation, journal checksum. fast fsck, etc. All you need to know is that these new features have improved the performance and reliability of the filesystem when compared to ext3.
In ext4, you also have the option of turning the journaling feature “off”.
Click to expand...
Click to collapse
I think ^^ means faster. Wonder if it is noticeable.
Either way, it's pretty cool that the EternityProject Kernel is the first one using this new fs on the Atrix.
Thanks again!
capnsouth said:
Thanks, Tao_Man, for the much easier to understand link.
I think ^^ means faster. Wonder if it is noticeable.
Either way, it's pretty cool that the EternityProject Kernel is the first one using this new fs on the Atrix.
Thanks again!
Click to expand...
Click to collapse
faux123 said:
Haha, the difference is EXT3 vs EXT4. I reverted back to EXT3 to be in line with cyanogenmod. I will release an EXT4 version sometimes later
Click to expand...
Click to collapse
Faux was using EXT4 for his CM7 kernel, but reverted back to EXT3 and people noticed a drop in quadrant numbers from 4000 to 3700 or so. not a HUGE difference, but enough that some people are gonna prefer the EXT4 kernel.
would it be possible to change the filesystem from ext4 to btrfs with compression and ssd optimization.
i do have the knowledge about the possible of having more cpu overhead than the improvement in transfer speed.. but when it comes to space saving, i think it does worth it. i have been using btrfs compression on opensuse for quite a while. the space saving is amazing. with compression enabled, the space usage is half the normal size.
the only concern im having about getting this to be done is the kernel. does the kernel we are using support btrfs compression at the first place(mblaster?)? i do not have the technical knowledge of how to get this done. hope someone could turn this idea to a reality.
gingerboy92 said:
...does the kernel we are using support btrfs compression at the first place(mblaster?)?
Click to expand...
Click to collapse
Nope, sorry. Btrfs is not in atm (could be changed for a test), but I don't know if compression would be supported. Also I am not convinced that compression would help a lot on the folio for two reasons: First the compression end uncompression both need cpu cycles, slowing down the system. And second the kind of files you typically have on such a device (mp3, videos etc.) are not really compressable. I doubt you would get more then a few percent more storage out of your device.
ehem.. about the cpu cycle, lzo compression could reduce the cpu usage, but i don't know by how much, probably still wouldn't worth the gain too. i don't know. but even if it does gives a worthy gain, maybe there's too much work to be done, lzo needs kernel 2.6.38 kernel to work if i'm not mistaken. compression(if possible) could be applied to something like the boot partition? maybe it could improve boot time, just a maybe.
looks like i didn't consider everything before i speak. thanks mblaster. ^.^
mblaster said:
Nope, sorry. Btrfs is not in atm (could be changed for a test), but I don't know if compression would be supported. Also I am not convinced that compression would help a lot on the folio for two reasons: First the compression end uncompression both need cpu cycles, slowing down the system. And second the kind of files you typically have on such a device (mp3, videos etc.) are not really compressable. I doubt you would get more then a few percent more storage out of your device.
Click to expand...
Click to collapse
True, what is stored on storage ? Mp3, mp4? ~ all of them are mostly compressed, where other - mathematical/lossles compression wouldnt help - in most cases would it make worse
gingerboy92 said:
ehem.. about the cpu cycle, lzo compression could reduce the cpu usage, but i don't know by how much, probably still wouldn't worth the gain too. i don't know. but even if it does gives a worthy gain, maybe there's too much work to be done, lzo needs kernel 2.6.38 kernel to work if i'm not mistaken. compression(if possible) could be applied to something like the boot partition? maybe it could improve boot time, just a maybe.
looks like i didn't consider everything before i speak. thanks mblaster. ^.^
Click to expand...
Click to collapse
compression is already applied on kernels.
usually you compile a kernel into bzImage, the "z" just means it's compressed.
modern linux kernels allow you to choose from gzip, bzip2, lzma, xz, lzo, lz4.
this includes ramdisk.
If you need space, just use an sdcard or microusb or Mount a network share...
Gesendet von meinem folio100 mit Tapatalk
Is it worth having zRAM on the HOX+? 1GB doesn't seem enough for multi-tasking, the device feels sluggish when switching between multiple applications.
From what I understand zRAM takes a chunk of the RAM and turns it into swap space, in compressed format. Of course, that means a bit less RAM available to apps traded for faster swap.
Any thoughts from the devs who have experience with zRAM? Worth the trouble?
Zram/compcache is a kernel feature, so unless you can get a kernel dev to include it in a kernel (or your able to compile your own kernel). This isnt an option for you.
Sent from my HTC One X+ using Tapatalk 2
Take a look here http://forum.xda-developers.com/showthread.php?t=2012320 and here http://forum.xda-developers.com/showpost.php?p=35510415&postcount=283
I recently read about the new f2fs format support in arter97's kernel thread and converting existing ext4 partition to f2fs.
However, it requires complete internal storage format and you will be also limited with kernel's that support it (right now I know only Agni and arter97 kernel's support it, might be others also I don't know). Also moving back to ext4 from f2fs is also untested ?
So, for those who already are on f2fs, please suggest what are the real world performance improvement like ? Does it really make the phone smooth or if there are any downsides for it, like more battery drain, app incompatibility, etc ? Benchmark numbers would also be good.
Others are also welcome to chip in
Also interested in this, some feedback from more experienced users in this matter would be appreciated.
Mafioso said:
So, for those who already are on f2fs, please suggest what are the real world performance improvement like ? Does it really make the phone smooth or if there are any downsides for it, like more battery drain, app incompatibility, etc ? Benchmark numbers would also be good.
Others are also welcome to chip in
Click to expand...
Click to collapse
http://forum.xda-developers.com/showpost.php?p=53298615&postcount=3084
thats my feedback for f2fs on temasek rom. (and also on stock room as it is my secondary rom)
in addition to your questions : no extra battery drain, and benchmarks are quite the same as on ext4. also there are no app incompatibilities.
btw. devil kernel supports f2fs as well
Darkened_Sky said:
http://forum.xda-developers.com/showpost.php?p=53298615&postcount=3084
thats my feedback for f2fs on temasek rom. (and also on stock room as it is my secondary rom)
in addition to your questions : no extra battery drain, and benchmarks are quite the same as on ext4. also there are no app incompatibilities.
btw. devil kernel supports f2fs as well
Click to expand...
Click to collapse
well that's a downer lol
For me it's working great.
Feels snappier and booting time is faster.
All apps are working.
Send From A Devil3 - f2fs - Dualboot Jb4.3/cm11 Powered Machine