Page 20 of 55 FirstFirst ... 10151617181920212223242530 ... LastLast
Results 381 to 400 of 1081
Like Tree13Likes
  1. #381  
    Quote Originally Posted by PreGP View Post
    If the F105 kernel gets updated, will I need to repeat the hack or will it survive an update?
    Updating a kernel would never modify any system files like Compcache or the sysctl.conf file we made. Quite the opposite, these files actually modify the kernel when it boots up.
  2. carrel's Avatar
    Posts
    425 Posts
    Global Posts
    426 Global Posts
    #382  
    Just a quick update... I am at 34 hours running with this way and all seems pretty good. There are occasional stutters, which are almost certainly swapping. But they are not long and not too frequent. I have really used my phone hard during this time. She definitely would not have survived this long before this change. The screen comes right on and apps start fast. Swap usage is holding steady with most of compcache used and a small amount of the swap partition used.

    I even put off the temptation to update Mode Switcher (an update is available) because the last update required a phone reboot and I want to see how long this will last.

    Thank you rmausser for writing up how to do this with InternalzPro. (I prefer ssh and a full size screen/keyboard.) My sysctl settings are slightly different, but that is just fine tuning.
    Last edited by carrel; 05/28/2011 at 11:31 AM. Reason: s/out/put/
  3. carrel's Avatar
    Posts
    425 Posts
    Global Posts
    426 Global Posts
    #383  
    Quote Originally Posted by grappler View Post
    Ah, I get it now . . . When the earlier poster said he did mkswap, etc., "by hand," I thought he meant they were to be entered at the command-line. Duh.
    Actually I did mean that I entered it at the command line. Anything that you do in a shell script, you can do on the command line (shell). I chose to do this at the command line because then it wouldn't automatically get re-done if the phone reboots. I was just being cautious because I was trying something significant on my primary phone. If it crashed or failed miserably, I wanted to increase the chance that a reboot would be able to start fresh, without this. Now that I have run this for 35 hours, I feel safe putting it in a startup script.

    As to why the mkswap didn't work for you: Did you reboot after changing the line in /etc/event.d/compcache ?
  4.    #384  
    just an update, pre- 2.1 f104 (my pre- is unhappy with 105) Govnah currently show memory/swap at 235/103 and my pre- is SNAPPY! I am amazed and loving it! Thanks again



    oh and do you think I should edit the first post to redirect from 74 to this most current test?
  5. #385  
    Quote Originally Posted by rmausser View Post
    What we are doing, is making essentially a pyramid of memory.


    1. On the top, we have real RAM, but less of it available.
    2. In the middle of the pyramid we have Compresses Cache.
    3. At the bottom we have disk swap.

    I can follow all this and I am sacrificing my Pre to the test as well!


    M.
  6. #386  
    Quote Originally Posted by loopytee View Post
    just an update, pre- 2.1 f104 (my pre- is unhappy with 105) Govnah currently show memory/swap at 235/103 and my pre- is SNAPPY! I am amazed and loving it! Thanks again



    oh and do you think I should edit the first post to redirect from 74 to this most current test?
    I think you should direct people to rmausser's post #372 and someone should make this thread sticky!
  7. carrel's Avatar
    Posts
    425 Posts
    Global Posts
    426 Global Posts
    #387  
    Quote Originally Posted by rmausser View Post
    Explanation:

    What we are doing, is making essentially a pyramid of memory.
    Which, by the way, is exactly what Palm tried to do. They did a similar pyramid with RAM, Compcache and Compcache backing store. However it seems there is a problem with the Compcache backing store. My guess is that the backing store has no knowledge of flash behavior. If it doesn't know about flash pages, it could easily use up all the backing store by leaving just a little bit of needed memory in a page when the rest is stale. Then the page can't be cleared and it moves on to a new page. And so on and so on... This fits the behavior we were all seeing.

    The VM system does know about flash and implements swap on flash much more intelligently. So I figured, why not try letting it do the job. Besides, the system gives me better tools to prioritize the two types of swap and then to observe how they are getting used. So far, the theory seems solid.
    inta likes this.
  8. #388  
    Quote Originally Posted by PreGP View Post
    I think you should direct people to rmausser's post #372 and someone should make this thread sticky!
    Lets not jump ahead of ourselves yet people, lets keep testing it for a bit and I want to test some other ideas I have in my head first before we make this sticky.

    Im going to try tweaking some settings to this method, and even try a very different method as well soon so stay tuned.

    Maybe we can eradicate even the tiny lags completely.

    What I know for sure is

    a) Lunasysmgr commented out to overcommit definitely makes things better regardless of any setting.

    What I want to try is

    a) Taking off sysctl.conf and just try Palms memory managment with 96mb compcache and the new disk swap

    b) Trying the older sysctl.conf settings with only 10mb of compcache (palm default) and the new disk swap

    c) Just 10mb compcache and new disk swap, no sysctl.conf

    I want to isolate what of the three changes is mostly responsible for making the phone better, the compcache size, the new disk swap, or sys.ctl.
    Then from there see what combination works the best, and from there just tiny tweaking of the settings till we get it as good as possible.

    Its hard to really know what is making things better without isolating each part. Then on top of that, one setting might make it better or worse, but isolation is still the best bet.

    If you guys want to help I would like to set up three testing settings.

    Test 1:


    The settings we are currently using

    Test 2:

    96MB compcache with new disk swap. No sysctl.conf settings (rename or move the file)

    Test 3:

    10MB compcache with new disk swap. No sysctl.conf. (rename or move the file)

    Test 4:

    10MB compcache with new disk swap. Set sysctl.conf to:

    Code:
    vm.swappiness = 20
    vm.vfs_cache_pressure = 200
    vm.dirty_expire_centisecs = 18000
    vm.dirty_writeback_centisecs = 6000
    For baseline make sure that you do at least these things.

    1) Open PDK game
    2) Check voicemail
    3) Text message some people
    4)Go on web browser, access some full page sites
    5) Open camera
    6)Watch youtube video
    7) Open a bunch of mojo apps at once

    Since we all have different phones you will have to record the changes based on compared to how your phone operates without any of these settings. (Stock, but keep the kernel and CPU settings the same, so if you overclock, dont modify that)

    Then state which test out of 4 you ran, and the results after a day of usage.

    I am going to do Test number 3 personally.

    Thanks.

    *****EDIT*****
    Ok so 10mb compcache officially sucks. So thats out of the question.

    Im trying 96mb with disk swap and no sysctl.conf. So far working great. no lag.
    Last edited by rmausser; 05/28/2011 at 04:53 PM.
  9. carrel's Avatar
    Posts
    425 Posts
    Global Posts
    426 Global Posts
    #389  
    Hmmmm, at 39 hours, my phone locked up. I had to pull the battery. :-(

    I can't say why it locked up. It was responsive right up to the end. It could be the something other than the VM system, but it could have been these changes too. But it was a good 39 hours, so I'm going to keep testing my config the way it was.
  10. #390  
    Quote Originally Posted by carrel View Post
    Hmmmm, at 39 hours, my phone locked up. I had to pull the battery. :-(

    I can't say why it locked up. It was responsive right up to the end. It could be the something other than the VM system, but it could have been these changes too. But it was a good 39 hours, so I'm going to keep testing my config the way it was.
    Most likely at 39 hours you ran out of swap. Once swap runs out and memory fills up its game over. The lag to push stuff from swap to disk just to make room to put things in memory is so great that nothing seems to function.
    Sprint pre -> Motorola Photon 4G
  11. #391  
    This is why I am trying 96mb compcache with new disk swap and no sysctl.conf settings.

    I have an inkling those sysctl.conf settings are too aggressive.
  12. #392  
    Quote Originally Posted by rmausser View Post
    This is why I am trying 96mb compcache with new disk swap and no sysctl.con settings.

    I have an inkling those sysctl.conf settings are too aggressive.
    I came up with those numbers because the defaults are even more aggressive. I was trying to slow down pdflush allowing time for the garbage collector to do it's thing trying to avoid swapping *known* garbage from clogging up the works.


    M.
  13. carrel's Avatar
    Posts
    425 Posts
    Global Posts
    426 Global Posts
    #393  
    Quote Originally Posted by theXfactor2011 View Post
    Most likely at 39 hours you ran out of swap. Once swap runs out and memory fills up its game over. The lag to push stuff from swap to disk just to make room to put things in memory is so great that nothing seems to function.
    Possible, but I don't think so. I have been checking swap usage regularly with 'swapon -s'. Since I first booted, swap filled continuously until all 96 megs of compcache filled and then 20 of the 100 megs of the swap partition filled. That was the peak and happened within 12 hours. After that, compcache stayed mostly full and swap fluctuated between 20 and 12 megs of usage. I last checked it about 2 hours before it hung and only 12 meg of swap was in use.
  14. #394  
    Quote Originally Posted by Xanadu73 View Post
    I came up with those numbers because the defaults are even more aggressive. I was trying to slow down pdflush allowing time for the garbage collector to do it's thing trying to avoid swapping *known* garbage from clogging up the works.


    M.
    I was referring to the sysctl.conf settings that I made.
  15. carrel's Avatar
    Posts
    425 Posts
    Global Posts
    426 Global Posts
    #395  
    Quote Originally Posted by Xanadu73 View Post
    I came up with those numbers because the defaults are even more aggressive. I was trying to slow down pdflush allowing time for the garbage collector to do it's thing trying to avoid swapping *known* garbage from clogging up the works.


    M.
    I think the direction you took was really good at alleviating the symptoms we were all seeing when using compcache backing store. However, with that gone and a proper swap partition, I'm not sure they are beneficial any more. I too am now running with no sysctl.conf changes. I think the linux defaults are likely very close to ideal. Hopefully we are now tweaking these values to minimize stuttering instead of stopping the entire VM system from clogging up.

    On the other hand I think vm.overcommit_memory may be more interesting to play with. Palm set it to 1 because they had to know that their system allocates more memory than it needs or uses. 1 allows unlimited overcommits, but 1 is dangerous. 0 does not restrict it to not over commit memory, but does reduce it somewhat. And why did Palm think they needed to be able to overcommit so much?? Maybe some rationed over committing is useful. I am running with it set to zero right now just to feel out the swap changes without too many variables. I might try setting vm.overcommit_memory to 2 and playing with the ratio. But not just yet...

    For more info, try this The Linux kernel: Memory
  16. #396  
    Quote Originally Posted by carrel View Post
    I think the direction you took was really good at alleviating the symptoms we were all seeing when using compcache backing store. However, with that gone and a proper swap partition, I'm not sure they are beneficial any more. I too am now running with no sysctl.conf changes. I think the linux defaults are likely very close to ideal. Hopefully we are now tweaking these values to minimize stuttering instead of stopping the entire VM system from clogging up.

    On the other hand I think vm.overcommit_memory may be more interesting to play with. Palm set it to 1 because they had to know that their system allocates more memory than it needs or uses. 1 allows unlimited overcommits, but 1 is dangerous. 0 does not restrict it to not over commit memory, but does reduce it somewhat. And why did Palm think they needed to be able to overcommit so much?? Maybe some rationed over committing is useful. I am running with it set to zero right now just to feel out the swap changes without too many variables. I might try setting vm.overcommit_memory to 2 and playing with the ratio. But not just yet...

    For more info, try this The Linux kernel: Memory
    I played with the overcommit a while back. I set it to 2 and tried with overcommit ratios of 25, 50,75, 80 and the os failed to boot. when I used a ratio of 100 it was able to boot. But that says you can overcommit as long as you request less then the total available memory. seemed kind of pointless. I bailed on the idea for some more interesting tests
    Sprint pre -> Motorola Photon 4G
  17. carrel's Avatar
    Posts
    425 Posts
    Global Posts
    426 Global Posts
    #397  
    Quote Originally Posted by theXfactor2011 View Post
    I played with the overcommit a while back. I set it to 2 and tried with overcommit ratios of 25, 50,75, 80 and the os failed to boot. when I used a ratio of 100 it was able to boot. But that says you can overcommit as long as you request less then the total available memory. seemed kind of pointless. I bailed on the idea for some more interesting tests
    Did you have swap configured when you did that?? I'm guessing that the VM system knows nothing about compcache backing store. With a setting of 2 and no swap, you would only have "ratio" percentage of ram to allocate from. I could see that failing badly.
  18. #398  
    Quote Originally Posted by carrel View Post
    Did you have swap configured when you did that?? I'm guessing that the VM system knows nothing about compcache backing store. With a setting of 2 and no swap, you would only have "ratio" percentage of ram to allocate from. I could see that failing badly.
    Good point. I don't think I had dedicated swap at the time. Just the compache and backing.
    Sprint pre -> Motorola Photon 4G
  19. carrel's Avatar
    Posts
    425 Posts
    Global Posts
    426 Global Posts
    #399  
    Quote Originally Posted by theXfactor2011 View Post
    Good point. I don't think I had dedicated swap at the time. Just the compache and backing.
    In fact... Now that you mention it, that would explain what Palm did. Because they were using backing store, they had no way for the VM system to accurately estimate the amount of available memory. So they simply allowed unrestrained allocation. Using a value of 2 would fail, and even a 0 would likely underestimate. So they threw in the towel and set it to 1.
  20. #400  
    Quote Originally Posted by carrel View Post
    In fact... Now that you mention it, that would explain what Palm did. Because they were using backing store, they had no way for the VM system to accurately estimate the amount of available memory. So they simply allowed unrestrained allocation. Using a value of 2 would fail, and even a 0 would likely underestimate. So they threw in the towel and set it to 1.
    That would explain it. I've been thinking about that off and on for a while now and couldn't figure out why they would do that (unless it was self-admitting that their code is buggy as hell, of course... ).

    Good show!


    M.

Posting Permissions