lkml.org 
[lkml]   [2009]   [Dec]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Async suspend-resume patch w/ completions (was: Re: Async suspend-resume patch w/ rwsems)


    On Wed, 16 Dec 2009, Rafael J. Wysocki wrote:
    >
    > The summarized data are below (the "big" numbers are averages and the +/-
    > numbers are standard deviations, all in milliseconds):
    >
    > HP nx6325 MSI Wind U100
    >
    > sync suspend 1482 (+/- 40) 1180 (+/- 24)
    > sync resume 2955 (+/- 2) 3597 (+/- 25)
    >
    > async suspend 1553 (+/- 49) 1177 (+/- 32)
    > async resume 2692 (+/- 326) 3556 (+/- 33)
    >
    > async+one-liner suspend 1600 (+/- 39) 1212 (+/- 41)
    > async+one-liner resume 2692 (+/- 324) 3579 (+/- 24)
    >
    > async+extra suspend 1496 (+/- 37) 1217 (+/- 38)
    > async+extra resume 1859 (+/- 114) 1923 (+/- 35)
    >
    > So, in my opinion, with the above set of "async" devices, it doesn't
    > make sense to do async suspend at all, because the sync suspend is actually
    > the fastest on both machines.

    Hmm. I certainly agree - your numbers do not seem to support any async at
    all.

    However, I do note that for the "extra patch" makes a big difference at
    resume time. That implies that the resume serializes on some slow device
    that wasn't marked async - and starting the async ones early avoids that.

    But without the per-device timings, it's hard to even guess what device
    that was.

    But even that doesn't really help the suspend cases, only resume.

    Do you have any sample timing output with devices listed?

    Linus


    \
     
     \ /
      Last update: 2009-12-16 16:51    [W:2.837 / U:0.500 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site