Results 1 to 10 of 10
  1.    #1  
    I spent some time this afternoon running some benchmarks for disk throughput using the PREEMPT kernel I compiled last night with all IO schedulers compiled in. I used the bonnie++ synthetic benchmark suite and then averaged the results, with the "best" and "worst" calculated out as follows:

    Best: (higher is better) Worst (lower is better)
    Anticipatory 8 Anticipatory 4
    CFQ 3 CFQ 4
    Deadline 6 Deadline 7
    Noop 4 Noop 3


    (Hmm, the formatting didn't come out the best, but hopefully the columns are still comprehensible - I would welcome an admin reformatting, if they wish).

    The "most best" scheduler in the test was anticipatory (especially if you have CPU time to spare); the "least worst" was noop. CFQ (the stock scheduler) is somewhere in the middle.

    I did this benchmark as multiple people were willing to handwave and state what they thought was "l337" and "best" or "sucky" but could not come up with numbers to back up these statements. The only source of benchmarking I found was Palm themselves, who (via a friendly developer) confirmed CFQ was chosen as a reasonable default (and I cannot argue with their choice there - it appears one of the least likely to impact performance adversely).

    I have attached the OpenOffice spreadsheet with my results (and I would recommend reading the introductory comments for the caveats). I would be interested to see anyone else's benchmark results, if they are willing to spend the time - especially if it is done using a suite other than bonnie++.

    Cheers, Steve
    Attached Files Attached Files
  2. stubbs's Avatar
    Posts
    425 Posts
    Global Posts
    442 Global Posts
    #2  
    From your benchmarks, the Anticipatory scheduler looks to have a significant gain. However, I don't really know what these numbers mean, or what they would translate to in real life. I've never looked at I/O schedulers before, but I'll check it out. Palm's choice of CFQ doesn't look that superb, at least from your benchmark, since Noop and Anticipatory outperform it or at least equal it in all cases. Maybe I'll try some benchmarks when I get some time.
  3.    #3  
    Palm's choice is more of a "least worst" option - pretty much middle of the pack. Noop seems to make preempt work much better. I'm fiddling around with kernels this evening to try to isolate it.

    Cheers, Steve
  4. stubbs's Avatar
    Posts
    425 Posts
    Global Posts
    442 Global Posts
    #4  
    Cool stuff. I've got to do a lot more learning before I understand a lot of this. Been a regular linux user/sysadmin for a couple of years, but I've never gotten into the low level stuff much. Desktops kernels just seem to provide good performance out of the box. Now I've got a reason to learn though!
  5.    #5  
    In my testing anticipatory is indeed perceptibly faster, although the phone (unsurprisingly) spends markedly more time at higher frequencies now. The good news for Palm is the optimal speed for anticipatory appears to be 500MHz:

    palm-webos-device stats # cat time_in_state
    800000 44991
    720000 14867
    600000 6173
    550000 1117
    500000 553303
    250000 1289
    125000 14521
    palm-webos-device stats #

    The bad news for Palm is it's a bit of a nightmare getting pre-empt and anticipatory working together. I have a sneaking suspicion there is an alignment bug but tracing it is going to involve figuring out kgdboe and getting that going in my environment since I can't really disassemble my work phone to get at the pads for serial access.

    Cheers, Steve
  6.    #6  
    In my testing anticipatory is indeed perceptibly faster, although the phone (unsurprisingly) spends markedly more time at higher frequencies now. The good news for Palm is the optimal speed for anticipatory appears to be 500MHz:

    palm-webos-device stats # cat time_in_state
    800000 44991
    720000 14867
    600000 6173
    550000 1117
    500000 553303
    250000 1289
    125000 14521
    palm-webos-device stats #

    The bad news for Palm is it's a bit of a nightmare getting pre-empt and anticipatory working together. I have a sneaking suspicion there is an alignment bug but tracing it is going to involve figuring out kgdboe and getting that going in my environment since I can't really disassemble my work phone to get at the pads for serial access.

    Cheers, Steve
  7. stubbs's Avatar
    Posts
    425 Posts
    Global Posts
    442 Global Posts
    #7  
    Here's an interesting article that explains on a fairly high level how schedulers work.
    Kernel Korner - I/O Schedulers | Linux Journal

    What's piquing my curiosity is the fact that these schedulers are written for hard disk drives, while almost all mobile devices and many new laptops, etc., are using solid state media, which I suspect could be made to work much better with different algorithms. The whole theory changes! I've got to see if I can dig more up on this.
  8. #8  
    This is an interesting read. Lately it seems as if more people are recommending noop as the best option. I'd be interested to see your tests run again with the newer kernels like sr71.
  9. #9  
    Quote Originally Posted by peterlemonjello View Post
    This is an interesting read. Lately it seems as if more people are recommending noop as the best option. I'd be interested to see your tests run again with the newer kernels like sr71.
    No kidding, right... with the new kernels that are being developed their is a lot of possibility for optimizing the kernels to specific chosen task in concordance between the I/O scheduler and TCP Congestion algorithm chosen. For instance I'm using Ampache Mobile and AmpachPre and consistantly have problem with my windows server running AMpache receiving multiple request for the stream URL which is causing process duplication in Windows for my command line encoders. This only happens with my WebOS clients, both of them, so I'm positive that it has something to do with the way WebOS makes it call back request, so changing the way I/O scheduling and TCP congestion is handled may alleviate this.... looks like its time for some testing....
  10. #10  
    i hope you'd benchmark it on uberkernel running 800mhz too!

Posting Permissions