Page 26 of 55 FirstFirst ... 16212223242526272829303136 ... LastLast
Results 501 to 520 of 1081
Like Tree13Likes
  1. #501  
    I have a GSM pixi plus running webos 2.1. I changed the settings using internalz pro using the recommended settings (as follows):

    Quote Originally Posted by rmausser View Post
    THESE NEW SETTINGS ARE AMAZING!!

    Just had to say. Good work everyone. My phone is usable again. THANK GOD.

    To recap so far: (use Internalz Pro on the phone if ur not good with terminal to change these files BUT FIRST MAKE SURE that Internalz Pro is set to LINUX mode. To switch to linux mode open Internalz Pro and "left drop down menu>Preferences>Text Editor>Newline format: LINUX") Also scroll to the bottom of preferences and enable Master mode. BE CAREFUL, you now have the ability to modify system files with Internalz. Turn this off after you hack your phone so you dont delete something by mistake.

    Step 1: Change /etc/event.d/LunaSysMgr from:

    Code:
    echo "1" > /proc/sys/vm/overcommit_memory".
    to

    Code:
     #echo "1" > /proc/sys/vm/overcommit_memory".
    Step 2: Make a file in /etc called "sysctl.conf". Open the file with a text editor and write:

    Code:
     
    vm.swappiness = 90
    vm.vfs_cache_pressure = 200
    vm.dirty_expire_centisecs = 6000
    vm.dirty_writeback_centisecs = 1500
    Step 3: Open /etc/event.d/compcache.

    edit line 10 to say:

    Code:
     modprobe ramzswap disksize_kb=98304
    change line 10 to say ONLY that. Remove the part that says: dev/store/swap after it.

    then, after the line 12 in Compcache (swapon /dev/ramzswap0 -p 100, add:

    Code:
    mkswap /dev/store/swap
    swapon /dev/store/swap
    Reboot the phone. Enjoy.

    **I would highly recommend using the thundercheif F105 kernel if you can, as it overclocks the RAM to 200mhz, which will help with the slow speed of Compcache.**

    Explanation:

    What we are doing, is making essentially a pyramid of memory.

    On the top, we have real RAM, but less of it available. This is reserved only for applications that are currently being open or run and used, so they are responsive to the users input.

    In the middle of the pyramid we have Compresses Cache, or RAM that is being used as a compressed swap file. It is slower, but since it compresses the pages, there is more available for the phone to use than the Pre came with. It has the second priority, and is used for applications in the background and things that are not at your immediate attention.

    At the bottom we have disk swap. This is the slowest memory, but since we essentially have 8GB of memory on the phone, we could eventually turn this up to be even larger in size. Dirty pages and memory that is currently not being used at all, but the kernel thinks might be available on short notice, like background processes, lives here.

    We have organized the kernel to as quickly as possible dump any pages that arent being used to compcache, so that the faster ram is available for the app or device the user is using, hopefully eliminating lag. The advantage is that compcache increases the available amount of memory by compressing the pages, and therefore the kernel doesnt have to clean out the swap and ram as often, which is what is causing those long and painful lags we keep experiencing.

    **EDIT**

    changed memlimit to disksize.

    memlimit isnt working right and is stuck on 60mb according to /sbin/swapon -s. Dont know why.
    also i have set the governor to ondemand and from 122-600 scaling.

    are these settings any useful for a device having even less ram than the pre-?
    I experience that the phone now runs pretty stable (no lockups) but is not really fast. speed is not my first issue here. which change might improve speed but not sacrifice stability? battery drain is much higher than on 1.4.5, but that was also so before i changed the compcache settings.

    any others experimenting on the 2.1 pixi?
  2. #502  
    I need to update that page.

    I have since changed sysctl to this:

    Code:
     
    vm.swappiness = 90
    vm.vfs_cache_pressure = 200
    vm.dirty_expire_centisecs = 1800
    vm.dirty_writeback_centisecs = 6000
    Since the Pixi is a different device than the Pre you will really have to experiment.

    A different setting with a different approach I suggest is:

    Code:
     
    vm.swappiness = 30
    vm.vfs_cache_pressure = 200
    vm.dirty_expire_centisecs = 1800
    vm.dirty_writeback_centisecs = 6000
    and compcache turned off completely or set to something like 10MB or 32MB

    Quote Originally Posted by heino View Post
    I have a GSM pixi plus running webos 2.1. I changed the settings using internalz pro using the recommended settings (as follows):



    also i have set the governor to ondemand and from 122-600 scaling.

    are these settings any useful for a device having even less ram than the pre-?
    I experience that the phone now runs pretty stable (no lockups) but is not really fast. speed is not my first issue here. which change might improve speed but not sacrifice stability? battery drain is much higher than on 1.4.5, but that was also so before i changed the compcache settings.

    any others experimenting on the 2.1 pixi?
  3. #503  
    [QUOTE=rmausser;2981063]I need to update that page.

    I have since changed sysctl to this:

    Code:
     
    vm.swappiness = 90
    vm.vfs_cache_pressure = 200
    vm.dirty_expire_centisecs = 1800
    vm.dirty_writeback_centisecs = 6000
    so you are back to those settings again? what made you change back?
  4. rksand's Avatar
    Posts
    151 Posts
    Global Posts
    152 Global Posts
    #504  
    Quote Originally Posted by rmausser View Post
    ...Compression uses CPU power yes, but it does not require much RAM to do it....
    Doesn't the processor have some built in cache? Wouldn't it be used for something like compression?
  5. carrel's Avatar
    Posts
    425 Posts
    Global Posts
    426 Global Posts
    #505  
    Heino, I haven't heard from anyone else trying this on a Pixi. It would be great to have you try it and be a part of this.

    Some advice to you and everyone else. Go slow! As I have suggested in previous posts, please try a small number of changes and then try them for a good long time. Changing your settings every few hours tells you nothing. WebOS changes over time and the first 8 hours never seem to behave the same as it does after 24 hours and it's different again after 48. (It does seem to stabilize at around 48 hours for me, but I have to admit that I rarely get that far before something, maybe an app update, causes me to reboot.) You can speed that all up if you run a ton of apps, but the whole point is to test the phone the way YOU use it. Also if you change too many settings at once, it becomes impossible to tell what is causing improvements and what isn't. You are just shooting in the dark. Some in this thread are changing parameters wildly from one extreme to another after very short tests and each time claiming this is the best one yet. I just don't think we are learning much from that.

    My suggestion is that you start with post 419 and try just that for at least a full day. Then post 422 discusses changing compcache size and you may want to try that, but maybe not. After that, try some of the sysctl changes. I'm sure there will be a dozen new suggestions for those before you get to that point.

    Dave
  6. #506  
    [QUOTE=graffix31;2981066]
    Quote Originally Posted by rmausser View Post
    I need to update that page.

    I have since changed sysctl to this:

    Code:
     
    vm.swappiness = 90
    vm.vfs_cache_pressure = 200
    vm.dirty_expire_centisecs = 1800
    vm.dirty_writeback_centisecs = 6000
    so you are back to those settings again? what made you change back?
    im not back to those settings, just those are the settings I would use with 96mb of swap.
  7. #507  
    I have come to the conclusion that 96mb of compcache is the best setting for me at least.

    So, I will be keeping it at that and tweaking sysctl and other things around that.

    Unless of course we find a way to modify the disk swap size.
  8. #508  
    Quote Originally Posted by rmausser View Post

    Code:
     
    vm.swappiness = 30
    vm.vfs_cache_pressure = 200
    vm.dirty_expire_centisecs = 1800
    vm.dirty_writeback_centisecs = 6000
    and compcache turned off completely
    i have used these settings for the past 20 hours.
    there were some severe hickups when more cards were open (forums, preware, feeds, web, govnah). also after it wasn't used for 8 hours it acted really slow but recovered. the 96 mb compcache seemed to work smoother but i will try that one from tomorrow onwards (didn't let it run long enough to be reliable). so far memory is at 188 - 192 and swap at about 59 mb, read through govnah. swap seems to remain fairly constant. phone did not lock up, it did so regularly without these settings and only 10 mb of stock compcache.
  9. dave75's Avatar
    Posts
    796 Posts
    Global Posts
    806 Global Posts
    #509  
    I have been using swapiness at 100, compcache off, and garbage collector on. This is better than anything else I have tried but still gets moments where it slows down. It does recover if you don't use memory intensive apps like full web pages or camera. Not sure if we're ever going to get much better with only 256 M ram.
  10. #510  
    It appears to me that no matter how much compcache (i was using 256mb of it at one point even) there is something in the kernel that states:

    "when swap is > 100mb, start clearing stuff out like a mad man."

    That is when our phones lock up and then get iffy. It seems like the swap hits 100mb, then the kernel starts clearing stuff out, but only enough to get things back to say, 96mb. Then it fills again, and then back to 96mb, and the tiny lags repeat until you reboot.

    There needs to be somewhere that we can say "yo kernel, relax a bit ok? when things get to 100mb of swap dont freak out, wait till say 180mb (100mb swap and 96mb compcache) and then, flush everything out like crazy. Dont just bring it down to 170mb and then have it fill up in 5 minutes again"

    And if we somehow hack the disk swap to 512mb, then it will take even longer to get there.

    Maybe even a whole day, and then we can just preset reset every night to clear it out.
  11. #511  
    Sorry for being away seems like progress has been made. I figure I could share my settings now that I have had a few weeks of success.

    Code:
    root@Harry Palm Pre:/var/home/root# free -m
                 total       used       free     shared    buffers     cached
    Mem:           239        208         30          0          0         50
    -/+ buffers/cache:        156         82
    Swap:          199          0        199
    root@Harry Palm Pre:/var/home/root# free -m -s 120
                 total       used       free     shared    buffers     cached
    Mem:           239        235          4          0          0         71
    -/+ buffers/cache:        162         76
    Swap:          199          0        199
    
                 total       used       free     shared    buffers     cached
    Mem:           239        233          5          0          1         44
    -/+ buffers/cache:        187         52
    Swap:          199         10        189
    
                 total       used       free     shared    buffers     cached
    Mem:           239        233          5          0          1         39
    -/+ buffers/cache:        192         47
    Swap:          199         38        161
    
                 total       used       free     shared    buffers     cached
    Mem:           239        206         32          0          1         43
    -/+ buffers/cache:        161         78
    Swap:          199         35        164
    
                 total       used       free     shared    buffers     cached
    Mem:           239        217         22          0          2         48
    -/+ buffers/cache:        166         73
    Swap:          199         35        164
    
                 total       used       free     shared    buffers     cached
    Mem:           239        217         22          0          2         48
    -/+ buffers/cache:        166         73
    Swap:          199         35        164
    
                 total       used       free     shared    buffers     cached
    Mem:           239        222         17          0          3         51
    -/+ buffers/cache:        167         71
    Swap:          199         35        164
    
                 total       used       free     shared    buffers     cached
    Mem:           239        227         12          0          4         52
    -/+ buffers/cache:        170         68
    Swap:          199         35        164
    
                 total       used       free     shared    buffers     cached
    Mem:           239        226         12          0          4         52
    -/+ buffers/cache:        169         69
    Swap:          199         35        164
    
                 total       used       free     shared    buffers     cached
    Mem:           239        226         12          0          4         52
    -/+ buffers/cache:        169         69
    Swap:          199         35        164
    
                 total       used       free     shared    buffers     cached
    Mem:           239        230          9          0          4         52
    -/+ buffers/cache:        173         66
    Swap:          199         35        164
    
                 total       used       free     shared    buffers     cached
    Mem:           239        231          8          0          4         53
    -/+ buffers/cache:        173         66
    Swap:          199         35        164
    
                 total       used       free     shared    buffers     cached
    Mem:           239        225         13          0          4         53
    -/+ buffers/cache:        167         72
    Swap:          199         35        164
    
    
    root@HarryPalm Pre:/var/home/root#
    Above are some test results of using my settings. So the first memory read was taken after a clean reboot. the rest were every 2 mins while I did some stuff and then closed apps opened new ones etc and finally turning off the screen and watching some tv. Not too bad.

    So I'm using the standard 92 mb compcache without backing like most people at this point. (aka modifying the compcache file to say disksize_kb=98304) I have enabled the store swap (swapon /dev/store/swap -p -2). Now for the fun part the sysctl settings in /etc/sysctl.conf

    Code:
    vm.swappiness = 30
    vm.vfs_cache_pressure = 200
    vm.dirty_expire_centisecs = 1500
    vm.laptop_mode = 1
    vm.dirty_background_ratio = 5
    vm.dirty_ratio = 60
    vm.min_free_kbytes = 4096
    Yeah there are some new values that we have not looked at before.

    vm.dirty_ratio: percentage of overall memory, that is allowed to contain dirty pages before its flushed.

    vm.dirty_background_ratio: once flush starts, this is the percentage of memory that is allowed to remain dirty.

    Why those values, 60 because our phone is an ssd. 60 gives enough for application use so we dont purge during running the app but its not all the ram we have so I figure its a good buffer zone. 5% because once we start purging I dont want it to take forever and I figure it might not be a bad idea to leave some items behind just in case we open the app again.

    vm.laptop_mode, will fire a flush when we access the disk. so keep the stuff we are using and dump the rest.

    Finally the vm.min_free_kbytes is just the amount of memory reserved for kernel use. I started at 4 mb and I'm thinking of lowering it to 2 just to see what happens figure take all we can get. However, setting it too low may crash the phone.

    Good Luck.

    also one last mem check
    Code:
    root@Harry Palm Pre:/var/home/root# free -m
                 total       used       free     shared    buffers     cached
    Mem:           239        217         21          0          4         45
    -/+ buffers/cache:        167         71
    Swap:          199         35        164
    still seems to be working
    Sprint pre -> Motorola Photon 4G
  12. #512  
    I used these settings for the past 36 hours, mind that I use a GSM Pixi Plus running Webos 2.1.:

    Code:
     
    vm.swappiness = 90
    vm.vfs_cache_pressure = 200
    vm.dirty_expire_centisecs = 1800
    vm.dirty_writeback_centisecs = 6000
    and changed compcache in event.d to:

    Code:
    xvmalloc
    	modprobe ramzswap disksize_kb=98304
    	sleep 3
    	swapon /dev/ramzswap0 -p 100
            mkswap /dev/store/swap
            swapon /dev/store/swap
    (only a part copied from compcache)

    compared to the no compcache setting I used before the experience when using the phone has been much better. no hickups, lag only when launching 2 or 3 apps at the same time. the UI always felt smooth. now swap is at 79 mb (after 36 hours) and the phone is still responsive. battery drain also was much lower but I dont know if these settings effect that, so I wouldnt rely on that.

    lets see what happens when swap reaches 100 mb. so far I am quite happy with the result since I now can make it over a day without a reboot.

    Best regards,

    Heino

    edit:

    1 hour later my phone did a luna restart. I am pretty sure that I reached the 100 mb limit on swap since I launched preware and tried to install sth.
    My thought: use 32 mb compcache instead of 96 as this frees up needed ram and is about the size when 100 mb swap is full (3:1 compresion ratio). Is this the right approach?
  13. carrel's Avatar
    Posts
    425 Posts
    Global Posts
    426 Global Posts
    #513  
    Quote Originally Posted by heino View Post
    1 hour later my phone did a luna restart. I am pretty sure that I reached the 100 mb limit on swap since I launched preware and tried to install sth.
    My thought: use 32 mb compcache instead of 96 as this frees up needed ram and is about the size when 100 mb swap is full (3:1 compresion ratio). Is this the right approach?
    Heino, I'd agree with your first sentence. Once swap is full, that likely means that all VM (Virtual Memory = RAM + compcache + swap) is full and the OOM killer will start killing apps and eventually luna will restart. (Actually a Luna restart is a good thing at that point. It is possible for the OOM killer to kill something that doesn't cause a Luna restart and then you are running in an unknown state.)

    On your second sentence though, I think I'd disagree. If you drop the size of compcache, then you do get more RAM, but your total VM size decreases. So you should end up running out of VM sooner. The tradeoff is more compcache == more VM, versus less compcache == greater performance.
  14. #514  
    Quote Originally Posted by heino View Post
    i have used these settings for the past 20 hours.
    there were some severe hickups when more cards were open (forums, preware, feeds, web, govnah). also after it wasn't used for 8 hours it acted really slow but recovered. the 96 mb compcache seemed to work smoother but i will try that one from tomorrow onwards (didn't let it run long enough to be reliable). so far memory is at 188 - 192 and swap at about 59 mb, read through govnah. swap seems to remain fairly constant. phone did not lock up, it did so regularly without these settings and only 10 mb of stock compcache.
    from what i understand you should not be running govnah for long periods of time. that is unless your trying to fill up your memory quickly to test. because it is constantly polling while open.
  15. carrel's Avatar
    Posts
    425 Posts
    Global Posts
    426 Global Posts
    #515  
    I did a bunch more work this weekend on increasing swap size.

    One approach is to create a swap file. I'm going to do this tonight. It's not a perfect solution because it will block USB mode from working. But it should at least test out the concept. As others have pointed out, I don't think performance will suffer versus increasing the size of the swap partition.

    The other approach is to increase the size of the swap partition. I think this is the best option, but it is hard and I spent all the time I had available this weekend working on this and I couldn't make it all work. Basically two things must happen. The partitions must be resized and the LVMs must be resized. The latter is easy. Resizing the swap partition is easy. But resizing (shrinking) /media/internal is not easy. It is a VFAT partition. WebOS provides two tools that could likely do the resizing. 'parted' and 'resizefat'. Unfortunately parted isn't displaying the partition table properly so I think it likely will not handle the job gracefully. And resizefat has no documentation (other than '--help') and I can't find the source on the net. The next hurdle is that I can't easily unmount /medial/internal and I highly doubt that resizefat is smart enough to be able to cleanly resize a "live" partition. In order to get it unmounted, the best solution that I can come up with is membooting a rescue kernel and going in and doing the resizing via novacom.

    The issues I mention with parted and resizefat have lead me to be unwilling to experiment on my primary phone. At least not yet. If anyone can lend any knowledge on those issues it would be very helpful.

    For parted, try running '/usr/sbin/parted /dev/mapper/store-media print'. Why does it recognize the partition as msdos formatted, but show no partition table? (Try running that same command on store-root for comparison.)

    For resizefat, any ideas where the sources came from? Does Palm post their sources? If it is GPL (which is a big IF) don't they have to? My google-fu is bad so maybe someone else will have better luck tracking down the sources.
  16. #516  
    I just discovered this thread. is there any new developements since post 74? did someone create a clear step by step set of instructions yet?

    thanks for all your work guys!
    Last edited by blackfireball5; 06/06/2011 at 04:55 PM.
  17. #517  
    Resizing the partitions will likely to leave you without OTA support for upgrades. I would suggest an approach that uses swap files and automatically unmounts them when you want to use USB mode. This could be graceful and prompt you to shut down extra ptograms etc.
  18. #518  
    so are you sticking with the info in the post referenced in the first post as the best settings to use right now?
  19. #519  
    Quote Originally Posted by graffix31 View Post
    so are you sticking with the info in the post referenced in the first post as the best settings to use right now?
    Was this directed to me? If so I'm an interested bystander. I have 1.4.5.1 on a VZW Pre Plus and find I rarely use swap so this optimization is of interest but not essential to me.

    Nothing to see here... question answered below.
    Last edited by Unclevanya; 06/06/2011 at 01:03 PM.
  20. #520  
    No i meant carrel.

Posting Permissions