All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: Joerg Roedel <joro@8bytes.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Len Brown <len.brown@intel.com>,
	linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/6 v2] PM / Hibernate: Memory bitmap scalability improvements
Date: Mon, 21 Jul 2014 14:00:53 +0200	[thread overview]
Message-ID: <20140721120053.GA14069@amd.pavel.ucw.cz> (raw)
In-Reply-To: <1405938422-21900-1-git-send-email-joro@8bytes.org>

Hi!

> * Rebased to v3.16-rc6
> * Fixed the style issues in Patch 1 mentioned by Rafael
> 
> Hi,
> 
> here is the revised 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).

Why are we doing random access there?

Is the improvement from fact that normally very little memory is used
on big memory machines?

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

Actually... how long does it take to hibernate 12TB machine? That
should be many hours, right? You just can't hibernate machine that
big.

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

Ok, so what about simpler patch? Just touch the watchdog?

Additional 70 seconds will be lost in noise if you write 12TB of RAM
to (even quite fast) disk.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

  parent reply	other threads:[~2014-07-21 12:00 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-21 10:26 [PATCH 0/6 v2] PM / Hibernate: Memory bitmap scalability improvements Joerg Roedel
2014-07-21 10:26 ` [PATCH 1/6] PM / Hibernate: Create a Radix-Tree to store memory bitmap Joerg Roedel
2014-07-21 22:36   ` Joerg Roedel
2014-07-21 23:05     ` Pavel Machek
2014-07-21 10:26 ` [PATCH 2/6] PM / Hibernate: Add memory_rtree_find_bit function Joerg Roedel
2014-07-21 10:26 ` [PATCH 3/6] PM / Hibernate: Implement position keeping in radix tree Joerg Roedel
2014-07-21 10:27 ` [PATCH 4/6] PM / Hibernate: Iterate over set bits instead of PFNs in swsusp_free() Joerg Roedel
2014-07-21 10:27 ` [PATCH 5/6] PM / Hibernate: Remove the old memory-bitmap implementation Joerg Roedel
2014-07-21 10:27 ` [PATCH 6/6] PM / Hibernate: Touch Soft Lockup Watchdog in rtree_next_node Joerg Roedel
2014-07-21 12:00 ` Pavel Machek [this message]
2014-07-21 12:36   ` [PATCH 0/6 v2] PM / Hibernate: Memory bitmap scalability improvements Joerg Roedel
2014-07-21 13:06     ` Pavel Machek
2014-07-21 13:38       ` Joerg Roedel
2014-07-21 14:10         ` Pavel Machek
2014-07-21 16:03           ` Joerg Roedel
2014-07-21 23:05             ` Pavel Machek
2014-07-22  0:41               ` Rafael J. Wysocki
2014-07-22 10:34                 ` Joerg Roedel
2014-07-22 10:55                   ` Pavel Machek
2014-07-22 12:24                     ` Joerg Roedel
2014-07-22 10:58                   ` Pavel Machek
2014-07-22 12:10                     ` Joerg Roedel
2014-07-23 10:57                       ` Pavel Machek
2014-07-28 13:59                   ` Borislav Petkov
2014-07-29 21:22                     ` Rafael J. Wysocki

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=20140721120053.GA14069@amd.pavel.ucw.cz \
    --to=pavel@ucw.cz \
    --cc=joro@8bytes.org \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=rjw@rjwysocki.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.