maemo.org - Talk

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)

Mentalist Traceur 2011-02-17 23:58

Re: Massive interactivity improvement under high I/O load!
 
Quote:

Originally Posted by TiagoTiago (Post 949299)
the last line gives me:
Code:

-sh: cannot create /sys/block/mmcblk1/queue/nr_requests: nonexistent directory
Is that 'cause i don't got an SD card?

Yes, as I understand it, that's exactly why. Run "ls" on the "/sys/block" directory. If there's no mmcblk1 folder in there, then your device just doesn't see that piece of hardware - not having it in there at all being a logical reason for it not being able to see it.

retsaw 2011-02-18 00:36

Re: Massive interactivity improvement under high I/O load!
 
Quote:

Originally Posted by joerg_rw (Post 948943)
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

Do you know what the MMC-driver actually does? It appears to simply make the device unavailable without unmounting it, but appearances can be deceiving so maybe it does more than that.

And when you say ruin, do you mean simply corrupt the data on it by not leaving it in a clean state or do you mean electrically damage so it can't be used again? If you just mean might corrupt the data on the card, I don't see how the driver removing the device without unmounting the filesystem is any better than yanking the card.

Mentalist Traceur 2011-02-18 02:53

Re: Massive interactivity improvement under high I/O load!
 
(Typing this on the FastSMSEvo keyboard in portrait mode - N900 sure has come far with so little manufacturer support.) Anyway, I'm pretty certain it unmounts it. Simply making the card/MyDocs unaccessible would be useless for the only reason that's even implemented - making sure the file systems/partitions don't get raped. Nokia execs might be stupid but their programmers aren't, mostly.

And, yes, were talking about corruption digitally, not physical damage.

So yes, that is different than making the cards inaccessible. (If cards were inaccessible but mounted, I'm pretty sure it would mess up your storage just about every time you used Mass Storage mode, without jumping through way too many hoops. Just a guess though, I am by no means an expert.)

joerg_rw 2011-02-18 12:53

Re: Massive interactivity improvement under high I/O load!
 
Quote:

Originally Posted by retsaw (Post 949346)
... And when you say ruin, do you mean simply corrupt the data on it by not leaving it in a clean state or do you mean electrically damage so it can't be used again?

I mean electrical (or lowest level logical) damage caused by breaking power supply so a erase or flash cycle gets aborted. (possible) Result: card defect, bin it.

/j

Tigerite 2011-02-18 16:49

Re: Massive interactivity improvement under high I/O load!
 
Quote:

Originally Posted by hawaii (Post 949022)
I also think scheduler changing (BFS?), ramzez and a change to SLUB/SLAB/SLOB/SLQB will yield the best results. The android kids have been messing with this stuff much more, unfortunately they don't always document it. They just drop kernel **** in a ROM and push it.


Not sure on the SLUB/SLAB/SLOB/SLQB argument, but ramzez is basically just a port of compcache. I've tried to incorporate it into the BFS kernel, but Nokia screwed around so much with the swapping code (to try to align pages) that unfortunately it's unstable, especially with the swap notify patch (even when I modified it to try to allow for their swap_remap nonsense). This can be shown up very easily by simply running two memhog's of around 200MiB at the same time - OOM is the usual result, with the occasional complete system crash. Lovely..

retsaw 2011-02-18 16:54

Re: Massive interactivity improvement under high I/O load!
 
Quote:

Originally Posted by joerg_rw (Post 949705)
I mean electrical (or lowest level logical) damage caused by breaking power supply so a erase or flash cycle gets aborted. (possible) Result: card defect, bin it.

/j

Thanks, then I guess if the driver cuts power to the slot what it does makes sense.

Tigerite 2011-02-18 17:29

Re: Massive interactivity improvement under high I/O load!
 
By the way, I meant to mention but didn't have much time to post; there is also an anti-stalling I/O patch which I successfully compiled into the BFS kernel - it's on the garage page now, although disabled by default:

https://garage.maemo.org/tracker/ind...1528&atid=5523

It should also be trivial to patch into kernel-power, if anyone is so inclined..

nightfire 2011-02-18 17:49

Re: Massive interactivity improvement under high I/O load!
 
Quote:

Originally Posted by Tigerite (Post 949877)
Not sure on the SLUB/SLAB/SLOB/SLQB argument, but ramzez is basically just a port of compcache. I've tried to incorporate it into the BFS kernel, but Nokia screwed around so much with the swapping code (to try to align pages) that unfortunately it's unstable, especially with the swap notify patch (even when I modified it to try to allow for their swap_remap nonsense). This can be shown up very easily by simply running two memhog's of around 200MiB at the same time - OOM is the usual result, with the occasional complete system crash. Lovely..

Just out of curiosity, have you tried running that memhog test with more min_free_kbytes?

qole 2011-02-18 22:36

Re: Massive interactivity improvement under high I/O load!
 
Quote:

Originally Posted by nightfire (Post 949047)
Thanks akpoff.. :)

Honestly my dream is to have a true laptop in my pocket with zero artificial limitations. I want to be able to travel anywhere with nothing more than a bluetooth keyboard and mouse.

Yeah me too. Still would like to figure out a way to throw it all onto a bigger display, somehow...

http://farm5.static.flickr.com/4091/...d13fe967_m.jpg

epitaph 2011-02-19 03:30

Re: Massive interactivity improvement under high I/O load!
 
I've tried this:

echo 4 > /sys/block/mmcblk0/queue/nr_requests
echo 200 > /proc/sys/vm/vfs_cache_pressure

from ur setting and it seems to me an improvment.

before i did this:

echo 4000 > /sys/block/mmcblk0/queue/nr_requests.

But I have this

echo 1250 > /proc/sys/vm/dirty_writeback_centisecs
echo 1250 > /proc/sys/vm/dirty_expire_centisecs

and

usr/bin/read-ahead /dev/mmcblk0p1 4000

and also i enabled

echo 1 > /proc/sys/kernel/sched_compat_yield

which i found a huge improvement.

I have compiled read-ahead myself. what do u think? did u tried my tools? did u ran bonnie++ before and after ur optimization? i did but i forgot the result. Anyway thank u for sharing i got a hard time with this device!


All times are GMT. The time now is 16:25.

vBulletin® Version 3.8.8