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: Wed, 23 Jul 2014 12:57:51 +0200	[thread overview]
Message-ID: <20140723105750.GB22675@amd.pavel.ucw.cz> (raw)
In-Reply-To: <20140722121022.GA31450@8bytes.org>

On Tue 2014-07-22 14:10:22, Joerg Roedel wrote:
> On Tue, Jul 22, 2014 at 12:58:12PM +0200, Pavel Machek wrote:
> > On Tue 2014-07-22 12:34:44, Joerg Roedel wrote:
> > > On Tue, Jul 22, 2014 at 02:41:29AM +0200, Rafael J. Wysocki wrote:
> > > > It looks like some specific need motivated the Joerg's work, however,
> > > > so let's just not dismiss the use case lightly without knowing it.
> > > 
> > > The motivation was to optimize the data structures for machines with
> > > large amounts of RAM without penalizing average machines. On a 12TB
> > > machine you are close to 100000 pages just for one bitmap. Scanning
> > > through that linearly to find a given bit just doesnt scale anymore in
> > > this case.
> > 
> > Can you produce backtrace where 12TB machine spends time during boot
> > with resume= parameter but no suspend image?
> > 
> > AFAICT swsusp_check() does not play with bitmaps.
> 
> I can ask for a backtrace, I currently don't have one. But I have
> perf-data for this case. It also shows that it spends most of its time
> with bitmap operations:
> 
> ~# 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) ]

Aha, but that's the userland code... suspend package, resume.c: 

        dev = open(snapshot_dev_name, O_WRONLY);
        if (dev < 0) {
                error = ENOENT;
                goto Free;
        }

        resume_dev = open_resume_dev(resume_dev_name, &swsusp_header);
        if (resume_dev == -ENOMEDIUM) {
                error = 0;
                goto Close;
        } else if (resume_dev < 0) {
                error = -resume_dev;
                goto Close;
        }

What your probably want to do is open_resume_dev first, and only
open(snapshot_dev_name...) if it finds correct signature.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

  reply	other threads:[~2014-07-23 10:57 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 ` [PATCH 0/6 v2] PM / Hibernate: Memory bitmap scalability improvements Pavel Machek
2014-07-21 12:36   ` 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 [this message]
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=20140723105750.GB22675@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.