Menu

Main Menu
Talk Get Daily Search

Member's Online

    User Name
    Password

    Massive interactivity improvement under high I/O load!

    Reply
    Page 6 of 18 | Prev |   4     5   6   7     8   16 | Next | Last
    Mentalist Traceur | # 51 | 2011-02-17, 23:58 | Report

    Originally Posted by TiagoTiago View Post
    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.

    Edit | Forward | Quote | Quick Reply | Thanks

     
    retsaw | # 52 | 2011-02-18, 00:36 | Report

    Originally Posted by joerg_rw View Post
    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.

    Edit | Forward | Quote | Quick Reply | Thanks
    The Following User Says Thank You to retsaw For This Useful Post:
    juise-

     
    Mentalist Traceur | # 53 | 2011-02-18, 02:53 | Report

    (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.)

    Edit | Forward | Quote | Quick Reply | Thanks
    The Following User Says Thank You to Mentalist Traceur For This Useful Post:
    juise-

     
    joerg_rw | # 54 | 2011-02-18, 12:53 | Report

    Originally Posted by retsaw View Post
    ... 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

    Edit | Forward | Quote | Quick Reply | Thanks
    The Following 4 Users Say Thank You to joerg_rw For This Useful Post:
    Estel, fw190, Mentalist Traceur, retsaw

     
    Tigerite | # 55 | 2011-02-18, 16:49 | Report

    Originally Posted by hawaii View Post
    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..

    Edit | Forward | Quote | Quick Reply | Thanks
    The Following 2 Users Say Thank You to Tigerite For This Useful Post:
    hawaii, Mentalist Traceur

     
    retsaw | # 56 | 2011-02-18, 16:54 | Report

    Originally Posted by joerg_rw View Post
    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.

    Edit | Forward | Quote | Quick Reply | Thanks

     
    Tigerite | # 57 | 2011-02-18, 17:29 | Report

    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..

    Edit | Forward | Quote | Quick Reply | Thanks
    The Following User Says Thank You to Tigerite For This Useful Post:
    Mentalist Traceur

     
    nightfire | # 58 | 2011-02-18, 17:49 | Report

    Originally Posted by Tigerite View Post
    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?

    Edit | Forward | Quote | Quick Reply | Thanks

     
    qole | # 59 | 2011-02-18, 22:36 | Report

    Originally Posted by nightfire View Post
    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...


    Edit | Forward | Quote | Quick Reply | Thanks
    The Following 5 Users Say Thank You to qole For This Useful Post:
    Helmuth, Lemonadium, nightfire, vi_, Xagoln

     
    epitaph | # 60 | 2011-02-19, 03:30 | Report

    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!

    Edit | Forward | Quote | Quick Reply | Thanks

    Last edited by epitaph; 2011-02-19 at 03:56.

     
    Page 6 of 18 | Prev |   4     5   6   7     8   16 | Next | Last
vBulletin® Version 3.8.8
Normal Logout