| Prev |   1   2   3     4   12 | Next | Last
maemo.org - Talk
Page 2 of 18
Show 40 post(s) from this thread on one page

maemo.org - Talk (https://talk.maemo.org/index.php)
-   Maemo 5 / Fremantle (https://talk.maemo.org/forumdisplay.php?f=40)
-   -   Massive interactivity improvement under high I/O load! (https://talk.maemo.org/showthread.php?t=69973)

Creamy Goodness 2011-02-17 04:07
Re: Massive interactivity improvement under high I/O load!
 
Quote:
Originally Posted by TiagoTiago (Post 948608)
How does this compare to Swappolube?
you can adjust most of these settings from swappolube, but its missing the
Code:
/proc/sys/vm/min_free_kbytes
/sys/block/mmcblk0/queue/nr_requests
/sys/block/mmcblk1/queue/nr_requests
why couldn't you look yourself?

Mentalist Traceur 2011-02-17 04:09
Re: Massive interactivity improvement under high I/O load!
 
Quote:
Originally Posted by nightfire (Post 948610)
Never heard of swappolube... :)

In any case, like Mentalist Traceur said, blocking I/O doesn't result in a failure, it just means the process read()s, write()s, etc.. won't return immediately, but only once there's sufficient room in the (now very small) queue.

The benefit is that some desktop application that needs to read a config file doesn't risk ended up at queue position 100, waiting for 99 I/Os to complete, because cp, tar, or samba wasn't able to burst all those writes through (write() blocked quickly).
Swappolube came from Hawaii's optimizations. Most of them are similar to yours, however they were more along the lines of reducing occurances of I/O in general, and reducing swapping when not necessary. Swappiness was set to 30, and a few other changes were made. dirty and dirty_background ratios were put really high, and he didn't reduce the queues... Eventually someone packaged those changes as "swappolube" as a script, then it got made into a GUI program. Anyway, the difference is hawaii's original mods aimed for a I/O less, I/O in efficient bursts approach, where as you seem to go for a I/O often, so that I/O doesn't build up.

That said, I personally have been fiddling to get my own combination of settings based on those original mods.What I personally want to see is as little swap as possible while I still have ram space, but I don't want it to zealously abandon swapping the way it would if swapping is made zero. I'll fiddle with this myself, let you know if it seems better than what I'm doing.

It seems more in line with what I've been trying to do, which is keep as little memory as possible from being forced into swap, while still allowing for swapping when it is 'needed', since the smaller queues and the smaller dirty ratios would help keep it from accumulating dirty pages.

I'm having stellarium downloading one of the more massive (8 of 9 I believe) catalogs right now over wifi, so I don't want to fiddle too much now, but I'll get back to you when I get that over with and have had time to write the changes to where I want them, and then rebooted.

nightfire 2011-02-17 04:10
Re: Massive interactivity improvement under high I/O load!
 
Quote:
Originally Posted by Creamy Goodness (Post 948629)
you can adjust most of these settings from swappolube, but its missing the
Code:
/proc/sys/vm/min_free_kbytes
/sys/block/mmcblk0/queue/nr_requests
/sys/block/mmcblk1/queue/nr_requests
why couldn't you look yourself?
I would, but I'm still trying to figure out how to workaround Samba's unwavering desire to pre-allocate writes... which don't cooperate with non-sparse-file enabled filesystems like the lowly fat32.

I'll take a look at swappolube later. :)

epitaph 2011-02-17 04:10
Re: Massive interactivity improvement under high I/O load!
 
Quote:
Originally Posted by Bratag (Post 948625)
As requested. As a side point. If this does what we think it does - then the issues with transmission essentially locking up the phone (ok really slowing it down) will be mitigated to some extent.

Code:
dirty_ratio: 95

dirty_background_ratio: 60

dirty_writeback_centisecs: 0

dirty_expire_centisecs: 0

min_free_kbytes: 2039

swappiness: 30

vfs_cache_pressure: 100

onboard_nr_requests: 128

sd_nr_requests: 128
This isn't the original values. I have others. Also OP is right it makes a huge difference but i strongly doubt that it will work with transmission which is strange enough.

epitaph 2011-02-17 04:15
Re: Massive interactivity improvement under high I/O load!
 
Quote:
Originally Posted by nightfire (Post 948628)
Exactly. I'm actually able to place phone calls, browse, and launch programs while writing at 8mb/sec! It was totally unusable before.
Can u try this with my tools? I'm just curious! In the original kernel swappiness is 100.

nightfire 2011-02-17 04:19
Re: Massive interactivity improvement under high I/O load!
 
Quote:
Originally Posted by Mentalist Traceur (Post 948631)
Swappolube came from Hawaii's optimizations. Most of them are similar to yours, however they were more along the lines of reducing occurances of I/O in general, and reducing swapping when not necessary. Swappiness was set to 30, and a few other changes were made. dirty and dirty_background ratios were put really high, and he didn't reduce the queues... Eventually someone packaged those changes as "swappolube" as a script, then it got made into a GUI program. Anyway, the difference is hawaii's original mods aimed for a I/O less, I/O in efficient bursts approach, where as you seem to go for a I/O often, so that I/O doesn't build up.

That said, I personally have been fiddling to get my own combination of settings based on those original mods.What I personally want to see is as little swap as possible while I still have ram space, but I don't want it to zealously abandon swapping the way it would if swapping is made zero. I'll fiddle with this myself, let you know if it seems better than what I'm doing.

It seems more in line with what I've been trying to do, which is keep as little memory as possible from being forced into swap, while still allowing for swapping when it is 'needed', since the smaller queues and the smaller dirty ratios would help keep it from accumulating dirty pages.

I'm having stellarium downloading one of the more massive (8 of 9 I believe) catalogs right now over wifi, so I don't want to fiddle too much now, but I'll get back to you when I get that over with and have had time to write the changes to where I want them, and then rebooted.
Yeah.. for myself, performance is less of an issue than stability and predictability. I don't mind if file transfers drop from 8mb/sec to 7mb/sec, but I can't stand waiting 5 seconds for a UI response or crashes due to deadlocks, so I'll eliminate burstiness at the cost of efficiency any day.

And for swap, it's one of those frustrating balances. We want to swap http://talk.maemo.org/images/icons/icon8.gifas much unused data out as we can (ie. X init and bootup code, shells hosting blocked scripts, etc) to free memory for stuff we care about yet don't want to swap out stuff we might want again (and in a hurry). My argument for a low swappiness factor is.. since we're under so much pressure anyway the system will not have trouble finding excuses to page out. :)

I wonder if it would be worth setting some binaries unswappable (ie. phone).

epitaph 2011-02-17 04:24
Re: Massive interactivity improvement under high I/O load!
 
My tools is using mlock to lock x into ram. It seems to work. U should try it. And also hawaii is a troll.

Mentalist Traceur 2011-02-17 04:30
Re: Massive interactivity improvement under high I/O load!
 
Quote:
Originally Posted by nightfire (Post 948637)
We want to swap http://talk.maemo.org/images/icons/icon8.gifas much unused data out as we can (ie. X init and bootup code, shells hosting blocked scripts, etc) to free memory for stuff we care about yet don't want to swap out stuff we might want again (and in a hurry). My argument for a low swappiness factor is.. since we're under so much pressure anyway the system will not have trouble finding excuses to page out. :)
Personally, I didn't even know so much useful-only-at-boot crap sat in the ram indefinitely. If these things sit in ram after boot, can't a script be written to simply get rid of all the stuff like that that wastes memory space?

Creamy Goodness 2011-02-17 04:35
Re: Massive interactivity improvement under high I/O load!
 
Quote:
Originally Posted by nightfire (Post 948633)
I would, but I'm still trying to figure out how to workaround Samba's unwavering desire to pre-allocate writes... which don't cooperate with non-sparse-file enabled filesystems like the lowly fat32.

I'll take a look at swappolube later. :)
nooooooooooooo not you, I'm mad at the Tiago guy because he posts like 10 useless things per day, I'm suggesting if he REALLY wanted to know, he could have looked.

qole 2011-02-17 04:37
Re: Massive interactivity improvement under high I/O load!
 
I wonder if this would fix the problems people have been having trying to decompress the Easy Debian image. Decompressing a 2GB image in MyDocs basically brings the system to its knees and takes over an hour.

I filed a bug and nobody had any idea what was wrong...


| Prev |   1   2   3     4   12 | Next | Last
All times are GMT. The time now is 20:19.
Page 2 of 18
Show 40 post(s) from this thread on one page

vBulletin® Version 3.8.8