Active Topics
-
[ANNOUNCE] MeeShop - new app store (10)
to Applications by aspergerguy - 16 hrs, 22 mins ago -
HTTP-401 Sfos-Builder when using /etc/ssu credentials (0)
to SailfishOS by insanelysexy - 1 day, 22 hrs ago -
Longtime users: What device(s) are you using today? (54)
to General by ryu1 - 4 days, 3 hrs ago -
Registering (1)
to General by Halftux - 6 days, 19 hrs ago - more...
omri |
2010-04-02
, 19:30
|
|
Posts: 14 |
Thanked: 14 times |
Joined on Apr 2010
|
#31
|
Originally Posted by plaban
Do you happen to remember the exact commands you used?
 |
|
2010-04-02
, 19:33
|
|
Posts: 395 |
Thanked: 107 times |
Joined on Dec 2009
@ India
|
#32
|
I used File Manager to format the card
|
|
2010-04-02
, 20:09
|
|
Posts: 1,258 |
Thanked: 672 times |
Joined on Mar 2009
|
#33
|
Originally Posted by Konceptz
emmc/sd behave worse than a harddrive really...
I think this is somewhat pointless as the reason for striping was to use both hard drive's spin speed to increase data rate where the bottleneck is always the hard drive.
In this case, "conventional" seek time bottlenecks are eliminated due to the type of memory. Unless something is wrong with implementation, the default swap setup should be pretty much 100% of the speed you can get for "virtual memory".
But there are far more factors than "it should work this way". Therefore, if many people are coming up with a much faster swap solution by switching to a class 6 card, maybe we can also see if we can't pinpoint the slow down? (ie. throughput, kernel handling, etc..)
The internal block size is something like 256k, if you write 4k (page size), then write 4K somewhere else, then the emmc/sd must internally read 256k, modify the 4k, write back 256k. This makes emmc/sd behave alot like a hard drive that hates seeks.
256 / 4 is 64, that is, worst case speed is the sequential write speed divided by 64. Or, in the case of a class 6 microsdhc card, the worst case speed is 96 kilobytes/sec.
Most swap activity is random I/O.
But anyway, even if this was not the case, striping across two devices doubles the bandwidth anyway.
| The Following User Says Thank You to shadowjk For This Useful Post: | ||
|
|
2010-04-02
, 20:26
|
|
Posts: 310 |
Thanked: 383 times |
Joined on Jan 2010
|
#34
|
Originally Posted by Konceptz
That's sequential raid; striped raid increases throughput by parallelizing I/O. The access time on flash might be low, but the throughput isn't high, so reading/writing concurrent devices should increase performance.
I think this is somewhat pointless as the reason for striping was to use both hard drive's spin speed to increase data rate where the bottleneck is always the hard drive.
In this case, "conventional" seek time bottlenecks are eliminated due to the type of memory. Unless something is wrong with implementation, the default swap setup should be pretty much 100% of the speed you can get for "virtual memory".
But there are far more factors than "it should work this way". Therefore, if many people are coming up with a much faster swap solution by switching to a class 6 card, maybe we can also see if we can't pinpoint the slow down? (ie. throughput, kernel handling, etc..)
Sequential raid has no effect on streaming I/O, but allows concurrent yet disparate requests to execute concurrently.
Having said all that, I was hoping to reduce disk load on the internal MMC so that its queue would stay more empty. But, someone pointed out that most of the system is on another block device anyway, so it would only affect /home (ie. opt, user files, etc).
*edit* I just re-read your post and my response might not make sense.
I meant that striping across multiple devices increases bandwidth at the cost of slightly increasing access time. Sequential raid has no effect on bandwidth, but can reduce access time in some cases. In our case, striping across two block devices (ie. internal MMC + SD) could help us increase total swap bandwidth.
Last edited by nightfire; 2010-04-02 at 20:29.
|
|
2010-04-02
, 20:34
|
|
Posts: 310 |
Thanked: 383 times |
Joined on Jan 2010
|
#35
|
Hmm.. I wonder if there are any potential performance gains by setting the page size to the MMC / SD block size (if possible) or forcing the kernel to only swap, say, 64 pages at a time. Is it possible the kernel is writing out 4kb pages in separate I/O operations?
|
|
2010-04-02
, 20:36
|
|
Posts: 208 |
Thanked: 17 times |
Joined on Jan 2010
@ Belgium
|
#36
|
can we do something wrong with running this scripts? is this more pro or can a noobie dare the same?
|
|
2010-04-02
, 21:07
|
|
Posts: 97 |
Thanked: 30 times |
Joined on Dec 2009
@ Russia, Moscow
|
#37
|
Originally Posted by nielsvg
A good rule is if you don't understand what a command does - don't run it or be ready to reflash. At least "fdisk", rest are mostly harmless.
can we do something wrong with running this scripts? is this more pro or can a noobie dare the same?
edit: "mkswap /dev/mmcblk1p1" will erase all data on a sd card ofc.
|
|
2010-04-03
, 09:33
|
|
Posts: 1,258 |
Thanked: 672 times |
Joined on Mar 2009
|
#38
|
page-cliuster size is already set to 128k, iirc. It helps at the start, but after some time the swap area has become fragmented enough that swapout becomes more 4k random writes
|
|
2010-04-03
, 09:35
|
|
Posts: 395 |
Thanked: 107 times |
Joined on Dec 2009
@ India
|
#39
|
Did a test,at first run 30 apps at the same time without sd swap.After that rebooted and created swap in micro sd and run same 3p apps.I noticed that there is a little performance increase.
|
|
2010-04-03
, 20:40
|
|
Posts: 310 |
Thanked: 383 times |
Joined on Jan 2010
|
#40
|
Originally Posted by shadowjk
Oh I meant the RAM page size. I don't know if it's adjustable on the CPU/MMU or not, but with 256k the atomic unit, you could only ever page in/out 256k.
page-cliuster size is already set to 128k, iirc. It helps at the start, but after some time the swap area has become fragmented enough that swapout becomes more 4k random writes