linux-kernel - Re: [PATCH 0/6 v2] PM / Hibernate: Memory bitmap scalability improvements

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140721120053.GA14069@amd.pavel.ucw.cz>
Date:	Mon, 21 Jul 2014 14:00:53 +0200
From:	Pavel Machek <pavel@....cz>
To:	Joerg Roedel <joro@...tes.org>
Cc:	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Len Brown <len.brown@...el.com>, linux-pm@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/6 v2] PM / Hibernate: Memory bitmap scalability
 improvements

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/