![]() |
2010-09-17
, 18:55
|
Posts: 992 |
Thanked: 995 times |
Joined on Dec 2009
@ California
|
#72
|
I really really think someone should try and package COMPCACHE for the N900. It may make a huge difference, by providing fast intermediate swap area in RAM (where swapped out pages are stored in gzipped form).
![]() |
2010-09-17
, 19:00
|
|
Posts: 1,210 |
Thanked: 597 times |
Joined on Apr 2010
@ hamburg,germany
|
#73
|
![]() |
2010-09-17
, 19:07
|
Posts: 50 |
Thanked: 5 times |
Joined on Nov 2009
|
#74
|
![]() |
2010-09-17
, 19:09
|
|
Posts: 353 |
Thanked: 166 times |
Joined on Jun 2010
@ India
|
#75
|
![]() |
2010-09-17
, 19:10
|
Posts: 182 |
Thanked: 69 times |
Joined on Nov 2009
@ Netherlands
|
#76
|
I know for sure that the swappiness thing helps. You can test it by running Fennec or any other memory hogging application. The kill_oob_* thing looks sane, and so does the laptop_mode (based on its description found with Google). The tcp_* stuff is petty and probably does not make any difference to the network performance (unless somebody proves otherwise). Can't say much about the rest.
![]() |
2010-09-17
, 19:23
|
Posts: 156 |
Thanked: 28 times |
Joined on Dec 2009
@ Los Angeles, CA
|
#77
|
![]() |
2010-09-17
, 19:34
|
Posts: 1,418 |
Thanked: 1,541 times |
Joined on Feb 2008
|
#78
|
![]() |
2010-09-17
, 19:54
|
Posts: 2,829 |
Thanked: 1,459 times |
Joined on Dec 2009
@ Finland
|
#79
|
The Following User Says Thank You to slender For This Useful Post: | ||
![]() |
2010-09-17
, 20:03
|
Posts: 992 |
Thanked: 995 times |
Joined on Dec 2009
@ California
|
#80
|
Not necessarily. Given how expensive MMC access operations are, gzipping most pages to, let us say, 16MB of RAM may well prove to be faster than pushing the same pages to the MMC.
![]() |
Tags |
bada lubes, bada rox, swappiness, tuning |
Thread Tools | |
|
The flash block size is 128KBytes typical. That means - if you write a smaller block it is possible that hardware READS 128KB before, replace your small portion and write back. In this case it has a big sense to write by N * 128KB blocks to eliminate reads.
However, if you write sequentially, a smart hardware may have some buffering and it may determine that your next write is in the same 128KB block and combine it. In this case a size of page cluster less 128KB may have sense because it allows kernel interrupt page write operation and it accelerates a device reaction.
Unfortunately, I don't know - is eMMC hardware smart enough.