mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Joerg Roedel <joro@8bytes.org>
Cc: Pavel Machek <pavel@ucw.cz>, Len Brown <len.brown@intel.com>,
	linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/6] PM / Hibernate: Memory bitmap scalability improvements
Date: Sat, 19 Jul 2014 00:05:02 +0200	[thread overview]
Message-ID: <2105930.LcBFYOUaLE@vostro.rjw.lan> (raw)
In-Reply-To: <1405684643-30234-1-git-send-email-joro@8bytes.org>

On Friday, July 18, 2014 01:57:17 PM Joerg Roedel wrote:
> Hi,
> 
> here is a patch set to improve the scalability of the memory
> bitmap implementation used for hibernation. The current
> implementation does not scale well to machines with several
> TB of memory. A resume on those machines may cause soft
> lockups to be reported.
> 
> These patches improve the data structure by adding a radix
> tree to the linked list structure to improve random access
> performance from O(n) to O(log_b(n)), where b depends on the
> architecture (b=512 on amd64, 1024 in i386).
> 
> A test on a 12TB machine showed an improvement in resume
> time from 76s with the old implementation to 2.4s with the
> radix tree and the improved swsusp_free function. See below
> for details of this test.
> 
> Patches 1-3 that add the radix tree while keeping the
> existing memory bitmap implementation in place and add code
> to compare the results between both implementations. This
> was used during development to make sure both data
> structures return the same results.
> 
> Patch 4 re-implements the swsusp_free() function to not
> iterate over all pfns but only over the bits set in the
> bitmaps. This showed to scale better on large memory
> machines.
> 
> Patch 5 removes the old memory bitmap implementation now
> that the radix tree is in place and working correctly.
> 
> The last patch adds touching the soft lockup watchdog in
> rtree_next_node. This is necessary because the worst case
> performance (all bits set in the forbidden_pages_map and
> free_pages_map) is the same as with the old implementation
> and may still cause soft lockups. Patch 6 avoids this.
> 
> The code was tested in 32 and 64 bit x86 and showed no
> issues there.
> 
> Below is an example test that shows the performance
> improvement on a 12TB machine. First the test with the old
> memory bitmap:
> 
> # time perf record /usr/sbin/resume $sdev
> resume: libgcrypt version: 1.5.0
> [ perf record: Woken up 12 times to write data ]
> [ perf record: Captured and wrote 2.882 MB perf.data (~125898 samples) ]
> 
> real    1m16.043s
> user    0m0.016s
> sys     0m0.312s
> # perf report --stdio |head -50
> # Events: 75K cycles
> #
> # Overhead  Command         Shared Object                                   
> Symbol
> # ........  .......  .................... 
> ........................................
> #
>     56.16%   resume  [kernel.kallsyms]     [k] memory_bm_test_bit
>     19.35%   resume  [kernel.kallsyms]     [k] swsusp_free
>     14.90%   resume  [kernel.kallsyms]     [k] memory_bm_find_bit
>      7.28%   resume  [kernel.kallsyms]     [k] swsusp_page_is_forbidden
> 
> And here is the same test on the same machine with these
> patches applied:
> 
> #  time perf record /usr/sbin/resume $sdev
> resume: libgcrypt version: 1.5.0
> [ perf record: Woken up 1 times to write data ]
> [ perf record: Captured and wrote 0.039 MB perf.data (~1716 samples) ]
> 
> real    0m2.376s
> user    0m0.020s
> sys     0m0.408s
> 
> # perf report --stdio |head -50
> # Events: 762  cycles
> #
> # Overhead  Command      Shared Object                     Symbol
> # ........  .......  .................  .........................
> #
>     34.78%   resume  [kernel.kallsyms]  [k] find_next_bit
>     27.03%   resume  [kernel.kallsyms]  [k] clear_page_c_e
>      9.70%   resume  [kernel.kallsyms]  [k] mark_nosave_pages
>      3.92%   resume  [kernel.kallsyms]  [k] alloc_rtree_node
>      2.38%   resume  [kernel.kallsyms]  [k] get_image_page
> 
> As can be seen on these results these patches improve the
> scalability significantly. Please review, any comments
> appreciated.

Looks good.

How much testing did that receive?

Rafael


  parent reply	other threads:[~2014-07-18 21:46 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-18 11:57 Joerg Roedel
2014-07-18 11:57 ` [PATCH 1/6] PM / Hibernate: Create a Radix-Tree to store memory bitmap Joerg Roedel
2014-07-19  0:00   ` Rafael J. Wysocki
2014-07-19  7:57     ` Joerg Roedel
2014-07-18 11:57 ` [PATCH 2/6] PM / Hibernate: Add memory_rtree_find_bit function Joerg Roedel
2014-07-18 11:57 ` [PATCH 3/6] PM / Hibernate: Implement position keeping in radix tree Joerg Roedel
2014-07-18 11:57 ` [PATCH 4/6] PM / Hibernate: Iterate over set bits instead of PFNs in swsusp_free() Joerg Roedel
2014-07-18 11:57 ` [PATCH 5/6] PM / Hibernate: Remove the old memory-bitmap implementation Joerg Roedel
2014-07-18 11:57 ` [PATCH 6/6] PM / Hibernate: Touch Soft Lockup Watchdog in rtree_next_node Joerg Roedel
2014-07-18 22:05 ` Rafael J. Wysocki [this message]
2014-07-19  7:55   ` [PATCH 0/6] PM / Hibernate: Memory bitmap scalability improvements Joerg Roedel
2014-07-19 10:26 ` Pavel Machek
2014-07-19 11:35   ` Joerg Roedel
2014-07-19 13:49 ` Pavel Machek
2014-07-21  8:32   ` Joerg Roedel
2014-07-21 11:45     ` Pavel Machek
2014-07-21 14:29       ` Joerg Roedel
2014-07-21 14:39         ` Pavel Machek
2014-07-21 15:55           ` Joerg Roedel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2105930.LcBFYOUaLE@vostro.rjw.lan \
    --to=rjw@rjwysocki.net \
    --cc=joro@8bytes.org \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=pavel@ucw.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome