Active Topics

 


Reply
Thread Tools
Posts: 2,225 | Thanked: 3,822 times | Joined on Jun 2010 @ Florida
#31
Well, you lose access to whatever is swapped. Which is why you may just be very screwed. If/when I invest in that 32 GB class 10 MicroSD card I am hoping to acquire eventually, I will be happy to test this unmount-during-swapping scenario. Too lazy to do it with my current somewhat-small-capacity, slower ones.

Also, the above test I mentioned above while downloading catalog 8/9 was with Laptop mode on. I turned laptop mode off for this next test (catalog 9/9, significantly bigger) - while leaving the massive dirty (background) ratio values... So that combination was a bit less than ideal. Download speed was nice, but UI responsiveness ground to a halt in some moments... Hmmm, specifically, during the actual finishing of the download. It had the same horrible unresponsiveness during the previous test for about a minute or so, when it finished downloading that catalog.

So what does that tell us? Laptop mode on-off doesn't seem to effect either sustained downloading or the finalizing of the write of that file, that I could notice. By itself, however, it seems that just lowering the I/O queues, but not changing the ratios or the vfs_cache_pressure, doesn't solve the unresponsiveness problem.

On the other hand, for all I know, it does, and had this been an N900 with all values at stock, the same slowness/UI-paralysis could have lasted much longer, when downloading that big of a file and saving it, all the while having Stellarium running in the background, with real time and a decently wide viewing angle, plus twinkle for the stars enabled.

So, to sumrise, when using Stellarium's built in catalogue download, tweakings JUST the queue sizes down seems to increase download speed, but, if your dirty ratio and dirty background ratio are high, swappiness is low, you do NOT have regular pdf flush daemon wakeups enables (mine don't wake up automatically, I have both centisecs values at 0), there is still a massive slow-down when finishing the download.

My GUESS is that had I had the centisecs values set to something low, or the ratio values set to something low, both would have lessened the final slow-down as well, probably significantly, because with dirty ratio at 95 and dirty background ratio at 65, and no routine flush daemons waking up, the dirty pages built up, both in RAM and in swap, I suspect.

Speaking of which, Stellarium runs great with all star cataloges downloaded. This is the non-mobile one. The mobile one presumably does even better.
 
Posts: 2,802 | Thanked: 4,491 times | Joined on Nov 2007
#32
Originally Posted by epitaph View Post
Noop scheduler is activated by default
According to this thread (from post 21 onwards) the default is cfq.

and also u can't change a thing.
It should be a simple matter of "echo noop > /sys/block/mmcblk0/queue/scheduler".
 

The Following 4 Users Say Thank You to lma For This Useful Post:
Posts: 2,802 | Thanked: 4,491 times | Joined on Nov 2007
#33
On the subject of swap, do take a look at the ramzez and Diablo Turbo threads. On Diablo at least, ramzswap is the single most effective way to improve responsiveness when memory-starved (which is pretty much always if you're actually using the device).
 

The Following User Says Thank You to lma For This Useful Post:
Posts: 224 | Thanked: 155 times | Joined on Jan 2011
#34
Originally Posted by nightfire View Post
Hey everyone,

I've been using my phone as a wireless media server for friends (with Samba + wifi hotspot).
i just figured out how to do this yesterday, using the tablet mode hack.
http://talk.maemo.org/showthread.php?t=69912

do you have a more elegant way of doing this or is this the same method youre using?
 
Posts: 692 | Thanked: 264 times | Joined on Dec 2009
#35
I'm giving it a try, seems noticeably quicker right off the bat

Edit: Multitasking performance has REALLY improved. The performance increase from this is better than a 700Mhz overclock! Note: I'm also running swap-on-microSD.
__________________
"Impossible is not in the Maemo vocabulary" - Caballero

Last edited by GameboyRMH; 2011-02-17 at 14:13.
 

The Following User Says Thank You to GameboyRMH For This Useful Post:
joerg_rw's Avatar
Posts: 2,222 | Thanked: 12,651 times | Joined on Mar 2010 @ SOL 3
#36
Originally Posted by nightfire View Post
Generally speaking, Linux is tuned for rotating media, not flash memory. The VM and I/O schedulers try to group I/Os together in a sensible manner, to reduce disk thrashing.

Of course, it's meaningless on the n900; there is no penalty for discontinous I/O.
That's not entirely correct. flash memory has massive penalty on writing randomly to different erase pages. I planned to share a link here, but have to realize I can't find the one good one. Google might help, or ask shadowJK on #maemo IRC. Basically the point is - depending on number of buffers in MMC controller - the writing to a different erase page (wich are sized like e.g 128kb) makes the controller erase a flash-page and write the dirty internal buffer to flash, then read back to buffer the new page addressed, and finally modifies the content of buffer according to the pending IO. So for a sequence like write to 0x10000, 0x50000, 0xB0000 it makes almost no difference if the individual write IO is for 1 byte or 50kB - it's the erasing and rewriting of a whole page that takes xx milliseconds, while IO to the same erase page actually only modifies the RAM buffer in controller and takes no time at all.

Originally Posted by nightfire View Post
I wonder if it would be worth setting some binaries unswappable (ie. phone).
AFAIK a lot of elementary stuff already is mlocked, e.g rtcom-dialer-ui

What we really need is maybe a scheduler (plus kswapd) tailored to fit the exact operation mode and capabilities of the particular flash controller

/j
__________________
Maemo Community Council member [2012-10, 2013-05, 2013-11, 2014-06 terms]
Hildon Foundation Council inaugural member.
MCe.V. foundation member

EX Hildon Foundation approved
Maemo Administration Coordinator (stepped down due to bullying 2014-04-05)
aka "techstaff" - the guys who keep your infra running - Devotion to Duty http://xkcd.com/705/

IRC(freenode): DocScrutinizer*
First USB hostmode fanatic, father of H-E-N

Last edited by joerg_rw; 2011-02-17 at 14:59.
 

The Following 3 Users Say Thank You to joerg_rw For This Useful Post:
juise-'s Avatar
Posts: 186 | Thanked: 192 times | Joined on Jan 2010 @ Finland
#37
Originally Posted by slender View Post
What happens if back cover is removed intentionally or by accident during heavy swapping?
Tried it a few times (twice by accident, forgetting that I had swap on SD, once on purpose to test the effect), every time the system either hung or reset (can't remember which one). I don't think the system actually needs to be swapping at the moment, it's probably enough that the pages get lost.

It would be interesting to know whether the unmounting/disconnection of the SD card is done by SW or HW, and whether it can be prevented.
__________________
Trout have underwater weapons.
 

The Following 2 Users Say Thank You to juise- For This Useful Post:
joerg_rw's Avatar
Posts: 2,222 | Thanked: 12,651 times | Joined on Mar 2010 @ SOL 3
#38
Originally Posted by juise- View Post
It would be interesting to know whether the unmounting/disconnection of the SD card is done by SW or HW, and whether it can be prevented.
I'd guess it's done by the MMC-driver in kernel. There's definitely no hw switching off uSD slot the hard way, but given the fact you can ruin a card by inadvertently removing it, I won't suggest to override this mechanism.

/j
__________________
Maemo Community Council member [2012-10, 2013-05, 2013-11, 2014-06 terms]
Hildon Foundation Council inaugural member.
MCe.V. foundation member

EX Hildon Foundation approved
Maemo Administration Coordinator (stepped down due to bullying 2014-04-05)
aka "techstaff" - the guys who keep your infra running - Devotion to Duty http://xkcd.com/705/

IRC(freenode): DocScrutinizer*
First USB hostmode fanatic, father of H-E-N

Last edited by joerg_rw; 2011-02-17 at 14:53.
 

The Following 4 Users Say Thank You to joerg_rw For This Useful Post:
Posts: 2,225 | Thanked: 3,822 times | Joined on Jun 2010 @ Florida
#39
It would be interesting to know whether the unmounting/disconnection of the SD card is done by SW or HW, and whether it can be prevented.
Yes, because we want our SD cards corrupted if yanked out before unmounting.

It IS a good idea, but only in conjunction with swap relocating
scripts, in my opinion.
 

The Following 2 Users Say Thank You to Mentalist Traceur For This Useful Post:
Posts: 1,141 | Thanked: 781 times | Joined on Dec 2009 @ Magical Unicorn Land
#40
Originally Posted by slender View Post
What are disadvantages of using microSD as swap memory? What happens if back cover is removed intentionally or by accident during heavy swapping?
You answered your own question

I've been using SD for swap for a long time now and it makes a big improvement since it frees up eMMC i/o for other things besides swapping.

For testing the settings from this thread I moved swap back to eMMC to get a more fair comparison. If I can avoid using SD for swap I will.
 

The Following 3 Users Say Thank You to stlpaul For This Useful Post:
Reply


 
Forum Jump


All times are GMT. The time now is 18:51.