Re: [PATCH][RFC] swsusp: speed up image restoring on x86-64

From: Pavel Machek (pavel_at_suse.cz)
Date: 01/20/05

  • Next message: Chris Friesen: "Re: [bug?] strange behaviour with longjmp, itimer, and read/recv (but not pause) -- solved" 
    Date:	Thu, 20 Jan 2005 23:06:30 +0100
To: "Rafael J. Wysocki" <rjw@sisk.pl>

    Hi!

    > > > The following patch speeds up the restoring of swsusp images on x86-64
    > > > and makes the assembly code more readable (tested and works on AMD64). It's
    > > > against 2.6.11-rc1-mm1, but applies to 2.6.11-rc1-mm2. Please consifer for applying.
    > >
    > > Can you really measure the speedup?
    >
    > In terms of time? Probably I can, but I prefer to measure it in terms of the numbers of
    > operations to be performed.
    >
    > With this patch, at least 8 times less memory accesses are required to restore an image
    > than without it, and in the original code cr3 is reloaded after copying each _byte_,
    > let alone the SIB arithmetics. I'd expect it to be 10 times faster
    > or so.

    Well, 8 times less cr3 reloads may be significant... for the copy
    loop. Speeding up copy loop that takes ... 100msec?... of whole
    resume (30 seconds) does not seem too important to me.

    > The readability of code is also important, IMHO.

    It did not seem too much better to me.

    > > If you want cheap way to speed it up, kill cr3 manipulation.
    >
    > Sure, but I think it's there for a reason.

    Reason is "to crash it early if we have wrong pagetables".

    > > Anyway, this is likely to clash with hugang's work; I'd prefer this not to be applied.
    >
    > I am aware of that, but you are not going to merge the hugang's patches soon, are you?
    > If necessary, I can change the patch to work with his code (hugang, what do you think?).

    I think it is just not worth the effort.
                                                                                    Pavel 

    -- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
  • Next message: Chris Friesen: "Re: [bug?] strange behaviour with longjmp, itimer, and read/recv (but not pause) -- solved"

    Relevant Pages

    • Re: [patch 3/2] drivers/char/vt.c: remove unnecessary code
      ... Hey, that makes fully sense! ... a loop, and it remains fully readable. ... such a patch would be: ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH rc4-mm2 2/2] posix-timers: use try_to_del_timer_sync()
      ... The reason I ask is that this code, to the best of my knowledge, works and it ... also works if the timer is queued on another list prior to its being handled by ... We also note that this code is the subject of a patch to the RT patch to cover ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [RFC/PATCH 4/5] loop: execute in place (V2)
      ... I don't think loop on xip is performance critical. ... For page cache lookup ... Given that even without this patch we don't do page ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH] reduce swsusp casting
      ... There is no reason to be scared of ... I tried with both 2.6.8-rc2-mm1 with and without my patch and got ... Pat, since I'm sure you already have swsusp working on your machine, ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH] some more fixes for inode.c
      ... I don't see any reason why that should be the case; ... > iput() called for an inode which happens to have data in the page cache. ... could you please apply the patch? ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)