maemo.org - Talk
Page 5 of 5 « First 34 5
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)

Estel 2011-05-02 14:50
Re: Massive interactivity improvement under high I/O load!
 
Sorry for possibly lame question, but how swap fragmentation can occur o flash based disk? Doesn't hardware controller do "fragmentation" all the time no matter what, due to wear leveling? Especially, when swap is on microSD - I'm not certain if hardware wear leveling occur on eMMC, but SD cards got hardware wear leveling for sure, and as far as i know it is completely transparent for any software controller, IE. filesystem doesn't matter at all.

I would really like to read our specialist explanation on this though, cause it is highly possible that i missed something.

shadowjk 2011-05-02 19:30
Re: Massive interactivity improvement under high I/O load!
 
Wear leveling doesn't guarantee performance.

Flash erase blocks are some 256k - 1024k big.

On SD, MMC, eMMC and most USB flash keys, if you write 4k, the card takes an unused block, erases it, and writes that 4k to it. If you write other stuff to same block afterwards, it too gets written. If you go write somewhere else outside of that block, the card reads in the data missing from filling up 256k from the old block, marks old block unused, and writes it to new block.

Thus, if you're doing random 4k writes, the card ends up writing 256k for every request. Obviously that's 64 times slower.

Tigerite 2011-05-18 12:04
Re: Massive interactivity improvement under high I/O load!
 
Quote:
Originally Posted by shadowjk (Post 997934)
I have a script which looks at the output of 'iostat -m' command. When the amount of megabytes written to a swap partition exceeds the size of the swap partition, the fragmentation effects start. I store the megabytes written in a file after reswap(swapon temp, swapoff main, swapon main, swapoff temp) and keep track of bytes written after last reswap.
Hey, is this the script you speak of? I'm a bit confused as to why it's looking at mmcblk0p2, and also the swap bits at the end are giving me a headache trying to figure out ;)

vi_ 2011-05-18 12:35
Re: Massive interactivity improvement under high I/O load!
 
oooh boy, swap scripts! here is my swapswap script.

This script simply swaps the swap from one drive to the other. That means to 'refresh' the swap you would run it twice. The script is also able to automatically figure out which partition on the sdcard is the swap. It is partially based on a script suggested by 'whitewolf' in the 'swap on sd' thread.

Code:
#!/bin/sh
#swapswap
current_swap=$( cat /proc/swaps | awk '/mmcblk/ {print $1}' | cut -d "k" -f2 ut -c1)
drivelist=$(sfdisk -lnd /dev/mmcblk1)
swapmicro=$(echo "$drivelist" -n | grep Id=82 | awk '/mmcblk1/ {print $1}')

if [ "$current_swap" = "0" ]; then
        if [ "$swapmicro" ]; then
            swapon $swapmicro
            swapoff /dev/mmcblk0p3
        fi
#echo "swap is on sd"
elif [ "$current_swap" = "1" ]; then
        swapon /dev/mmcblk0p3
        swapoff $swapmicro
#echo "swap is on emmc"
fi

ya follow?



I have the following script run at 0330 to refresh the swap space.

Code:
#!/bin/sh
#check if device is not in use, if so swapswap!
brightness=$(cat /sys/class/backlight/acx565akm/brightness)
keyboard=$(cat /sys/devices/platform/gpio-switch/slide/state)

if [ "$brightness" == "0" ]; then
        if [ "$keyboard" == "closed" ]; then
                echo "/opt/scripts/swapswap.sh" | root
                echo "/opt/scripts/swapswap.sh" | root
        fi
fi
This checks to see if the device is in use (unlikly@0330. However you never know, I like my scripts to be bullet proof). If not, then it calls swapswap twice once to move it over, once to move it back.

shadowjk 2011-05-19 13:12
Re: Massive interactivity improvement under high I/O load!
 
Quote:
Originally Posted by Tigerite (Post 1009058)
Hey, is this the script you speak of? I'm a bit confused as to why it's looking at mmcblk0p2, and also the swap bits at the end are giving me a headache trying to figure out ;)

Because that's where my swap is.

Also, maemo renames mmcblk1 to mmcblk0 and other way around, but the old name sticks in some cases like iostat, but not swpon/swapoff.


This script is most likely unusable for anyone else. I only put it up on request from someone, to show him how I did it.

Tigerite 2011-05-19 15:39
Re: Massive interactivity improvement under high I/O load!
 
I wasn't meaning to be rude, simply trying to understand it and modify it for my own purposes. I didn't realise that about iostat - thanks for the pointer. I can see it swapons the "backup" swap, swapoffs the "normal" swap, updates reswap.stat (although earlier on in the script it doesn't specifically look in /root), then swapons the "normal" swap again before a final swapoff of the "backup" - but then it swapons the "backup" again, which is the bit I'm confused about?

By the way, I really appreciate the charge script found elsewhere on that same site - it's excellent! Thanks :)

shadowjk 2011-05-19 20:49
Re: Massive interactivity improvement under high I/O load!
 
I hope you're using charge21.sh which is newest right now...

I always run it out of /root, so iconsistencies in relative vs absolute paths never hit me

Additionally I have a script that I run on every boot, which among other things set reswap.stat to 0.

mmcblk0p3 is normal emmc swap. mmcblk1p3 in iostat.
mmcblk1p2 is microsd swap, mmcblk0p2 in iostat.

I leave emmc swap on, it sits at lower priority anyway, so I only have to do a swapoff if I want to remove back cover. No other particular reason. At one point I probably had a swapon binary with priority support and had emmc+usd at equal priority, but then I concluded performance was nicer when swap was dedicated to usd.

The general idea is indeed: swapon emmc, swapoff usd, swapon usd, swapoff emmc, swapon emmc.

vi_ 2011-05-19 21:19
Re: Massive interactivity improvement under high I/O load!
 
Quote:
Originally Posted by shadowjk (Post 1010431)
I hope you're using charge21.sh which is newest right now...

I always run it out of /root, so iconsistencies in relative vs absolute paths never hit me

Additionally I have a script that I run on every boot, which among other things set reswap.stat to 0.

mmcblk0p3 is normal emmc swap. mmcblk1p3 in iostat.
mmcblk1p2 is microsd swap, mmcblk0p2 in iostat.

I leave emmc swap on, it sits at lower priority anyway, so I only have to do a swapoff if I want to remove back cover. No other particular reason. At one point I probably had a swapon binary with priority support and had emmc+usd at equal priority, but then I concluded performance was nicer when swap was dedicated to usd.

The general idea is indeed: swapon emmc, swapoff usd, swapon usd, swapoff emmc, swapon emmc.
You have my attention. Please talk me through this charge script. What do you use it for? Do you feel bme is inadequate for your purposes?

shadowjk 2011-05-20 01:39
Re: Massive interactivity improvement under high I/O load!
 
Originally DocScrutinizer made a small script (it didn't work) prototype for charging without bme, probably intended as a prototype proof of concept for charging during hostmode operations. This was way before hostmode became working. I took the script and modified and built upon it (maybe 3 lines remaining from the original by now).

I had obtained a Mugen power battery and wanted to charge faster than bme. However, it turned out charging at higher rates produced almost exponentially more heat. So, I added thermal throttling to the charger, and was back at same rate.

We had previously observed a somewhat non-ideal charge curve from bme, and thought running the hw charger would fix that. Turned out to be caused by non-zero resistance in the circuit board.


Probably the only benefit is that you can charge without bme, and due to lack of checks, doesn't care about whether D+/D- is shorted or not. Might have side effect of frying USB ports on PCs, but I never myself charge from PC.

I should probably put warning at the top if people have discovered its existance and randomly downloading it.

Tigerite 2011-05-20 09:00
Re: Massive interactivity improvement under high I/O load!
 
I am using the latest charge21.sh, thanks for the detailed description of what it does and why. By the way the iostat included in busybox after installing busybox-power, when using kernel-power 47 at least, doesn't switch mmcblk0 and 1 around (thus my initial confusion). It's still a useful script which I'll no doubt modify for my own purposes ;)

Estel 2011-05-20 17:21
Re: Massive interactivity improvement under high I/O load!
 
Just to clarify things, frying PC ports should not be an issue, due to ocervurrent protection implemented in most modern OS'es, be it any linux, windows,mac or whatever. Normal outcome would be N900 charging @ max 500 mA from USB port, or 1A from 2 ports using Y-cable. Worst case scenario should be temporaly disabling on-topic USB port by OS, shouting @ user that peripherial device exceed current limitation drain.

Of course all of this is unless there is some bug in overcurrent protection, that I'm not aware of (which got high chances to be the case), so use at Your own risk.

Thanks for great scripts, shadowjediknight! :)

shadowjk 2011-05-20 23:22
Re: Massive interactivity improvement under high I/O load!
 
Lots of PCs lack adequate overcurrent protection...

I've seen one form where there's common overcurrent protection for several ports, so all ports go dead once protection kicks in.

Worst case is weak protection that works more like a fuse, permanently killing the port (but saving the PC)

The ideal is of course per-port resettable overcurrent protection, which notifies the OS on overcurrent condition.

I have a powered USB hub myself that gives about 700mA to my N900. However, everything else connected to it dims...

Tigerite 2011-05-21 07:42
Re: Massive interactivity improvement under high I/O load!
 
That's exactly what happened to my previous laptop - all of the ports suddenly died, presumably because of a combination of 1 and 2. Not pretty.

Estel 2011-05-22 00:41
Re: Massive interactivity improvement under high I/O load!
 
Thanks for the info... Fortunately, i got one with smart protection - otherwise i would screw it many years ago, when tried to check max port current with multimeter A measurement (which obviously made overcurrent prot. to go berseker - don't ask, it was one of most stupid ideas i had during my hardware modifications learning phase...). Fortunately, Os just shouted at me to get out with that, and disabled port until driver restart. Really good to know that there are fuse-based solutions still circulating...

By the way, out of curiosity - why everything else connected to that 700 mA port "dims"? Shouldn't peripheral things drain only as much as they need from port current "pool", so they don't care if port can provide 700 mA or 7A?

shadowjk 2011-05-22 15:28
Re: Massive interactivity improvement under high I/O load!
 
The charger chip in N900 happily operates at, for example, 4.5V input. The Hub's powersupply was unable to provide sufficient current, so voltage sagged to below 5V.

LTman 2011-05-23 20:25
Re: Massive interactivity improvement under high I/O load!
 
Looks like changing those values messes up pc suite file browsing + mass storage mode for windows


All times are GMT. The time now is 20:05.
Page 5 of 5 « First 34 5
Show 40 post(s) from this thread on one page

vBulletin® Version 3.8.8