On Monday, July 28, 2014 03:59:33 PM Borislav Petkov wrote:
> On Tue, Jul 22, 2014 at 12:34:44PM +0200, Joerg Roedel wrote:
> > So my test was to resume from a swap partition that contained no image.
> > Here is the result from the 16GB machine. First with a v3.16-rc6 kernel
> > without my changes:
On Tue, Jul 22, 2014 at 12:34:44PM +0200, Joerg Roedel wrote:
> So my test was to resume from a swap partition that contained no image.
> Here is the result from the 16GB machine. First with a v3.16-rc6 kernel
> without my changes:
>
> kv:~/base # time perf record /usr/sbin/resume /dev/sda1
> resu
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
On Tue, Jul 22, 2014 at 12:55:46PM +0200, Pavel Machek wrote:
> On Tue 2014-07-22 12:34:44, Joerg Roedel wrote:
> Writing out every single page on 12TB machine to disk does not scale,
> either :-).
But there is not much potential optimizing the write-out either (in
software). But that doesn't mea
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
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 t
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 t
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
On Tuesday, July 22, 2014 01:05:00 AM Pavel Machek wrote:
> Hi!
>
> On Mon 2014-07-21 18:03:46, Joerg Roedel wrote:
> > On Mon, Jul 21, 2014 at 04:10:27PM +0200, Pavel Machek wrote:
> > > > And Linux is only made for sane people? Thats pretty new to me ;-)
> > >
> > > Yeah, but please don't optim
Hi!
On Mon 2014-07-21 18:03:46, Joerg Roedel wrote:
> On Mon, Jul 21, 2014 at 04:10:27PM +0200, Pavel Machek wrote:
> > > And Linux is only made for sane people? Thats pretty new to me ;-)
> >
> > Yeah, but please don't optimize for insane people :-).
>
> Thats rather discriminating, even more w
Hi,
On Mon, Jul 21, 2014 at 04:10:27PM +0200, Pavel Machek wrote:
> > And Linux is only made for sane people? Thats pretty new to me ;-)
>
> Yeah, but please don't optimize for insane people :-).
Thats rather discriminating, even more when you realize that 'insane' is
a very subjective attribute
Hi!
> > > That would just cover the problem that the bitmap data structure and the
> > > algorithm in swsusp_free do not scale well on bigmem machines.
> >
> > And is it a problem? Hibernation of 12TB machine will take 6 hours if
> > you back your swap with SSDs.
> >
> > Does not scale == burns
Hi,
On Mon, Jul 21, 2014 at 03:06:29PM +0200, Pavel Machek wrote:
> > That would just cover the problem that the bitmap data structure and the
> > algorithm in swsusp_free do not scale well on bigmem machines.
>
> And is it a problem? Hibernation of 12TB machine will take 6 hours if
> you back yo
Hi!
> > > 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.
Hi,
On Mon, Jul 21, 2014 at 02:00:53PM +0200, Pavel Machek wrote:
> > 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
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 o
16 matches
Mail list logo
