All of lore.kernel.org
 help / color / mirror / Atom feed
From: pavel@ucw.cz (Pavel Machek)
To: linux-arm-kernel@lists.infradead.org
Subject: [linux-pm] [PATCH] PM: HIBERNATION: skip the swap size check if the snapshot image size is anticipative
Date: Fri, 18 Nov 2011 20:02:33 +0100	[thread overview]
Message-ID: <20111118190233.GA16136@elf.ucw.cz> (raw)
In-Reply-To: <CAGsJ_4xm05N4UZ94kvUtUGLGkcDnxesojV0fL9hQQnZBOFvohg@mail.gmail.com>

On Mon 2011-11-07 09:31:10, Barry Song wrote:
> 2011/11/6 Barry Song <21cnbao@gmail.com>:
> > 2011/11/6 Pavel Machek <pavel@ucw.cz>:
> >> Hi!
> >>
> >>> From: Barry Song <Baohua.Song@csr.com>
> >>>
> >>> Current swsusp requires swap partitions even larger than real saved pages
> >>> due to the worst compress ratio:
> >>> but for an embedded system, which has limited storage space, then it might
> >>> can't give the big size partition to save snapshot.
> >>> In the another way, some embedded systems can definitely know the most size
> >>> needed for snapshot since they run some specific application lists.
> >>> So this patch provides the possibility for bootloader to tell kernel even
> >>> the system has a little snapshot partition, but it is still enough.
> >>> For example, if the system need to save 120MB memory, origin swsusp will require
> >>> a 130MB partition to save snapshot. but if users know 30MB is enough for them(
> >>> compressed image will be less than 30MB), they just make a 30MB
> >>> partition.
> >>
> >> Would it be better to have /sys/power/... entry which would allow
> >> configuring expected compression ratio at runtime?
> >
> > i think it is better to have a sys node than add another kernel param.
> > but the point is i only care about the final image size but not
> > compression ratio. i don't care how well lzo will do for me since i
> > only have limited disk space and know how many pages want to be saved.
> > there has been a image_size node, will we have a expected_image_size node?
> 
> or will we have just a node named /sys/power/check_size, if
> 1(default), check, otherwise(0 set by users), skip checking?

Or just avoid the check at all, since it no longer makes sense with
compression?

What is the failure scenario? Hibernation still fails, but it takes
longer to fail?

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

WARNING: multiple messages have this Message-ID (diff)
From: Pavel Machek <pavel@ucw.cz>
To: Barry Song <21cnbao@gmail.com>
Cc: Barry Song <Barry.Song@csr.com>,
	Xiangzhen Ye <Xiangzhen.Ye@csr.com>,
	linux-kernel@vger.kernel.org, Barry Song <Baohua.Song@csr.com>,
	linux-pm@lists.linux-foundation.org,
	linux-arm-kernel@lists.infradead.org,
	DL-SHA-WorkGroupLinux <workgroup.linux@csr.com>
Subject: Re: [linux-pm] [PATCH] PM: HIBERNATION: skip the swap size check if the snapshot image size is anticipative
Date: Fri, 18 Nov 2011 20:02:33 +0100	[thread overview]
Message-ID: <20111118190233.GA16136@elf.ucw.cz> (raw)
In-Reply-To: <CAGsJ_4xm05N4UZ94kvUtUGLGkcDnxesojV0fL9hQQnZBOFvohg@mail.gmail.com>

On Mon 2011-11-07 09:31:10, Barry Song wrote:
> 2011/11/6 Barry Song <21cnbao@gmail.com>:
> > 2011/11/6 Pavel Machek <pavel@ucw.cz>:
> >> Hi!
> >>
> >>> From: Barry Song <Baohua.Song@csr.com>
> >>>
> >>> Current swsusp requires swap partitions even larger than real saved pages
> >>> due to the worst compress ratio:
> >>> but for an embedded system, which has limited storage space, then it might
> >>> can't give the big size partition to save snapshot.
> >>> In the another way, some embedded systems can definitely know the most size
> >>> needed for snapshot since they run some specific application lists.
> >>> So this patch provides the possibility for bootloader to tell kernel even
> >>> the system has a little snapshot partition, but it is still enough.
> >>> For example, if the system need to save 120MB memory, origin swsusp will require
> >>> a 130MB partition to save snapshot. but if users know 30MB is enough for them(
> >>> compressed image will be less than 30MB), they just make a 30MB
> >>> partition.
> >>
> >> Would it be better to have /sys/power/... entry which would allow
> >> configuring expected compression ratio at runtime?
> >
> > i think it is better to have a sys node than add another kernel param.
> > but the point is i only care about the final image size but not
> > compression ratio. i don't care how well lzo will do for me since i
> > only have limited disk space and know how many pages want to be saved.
> > there has been a image_size node, will we have a expected_image_size node?
> 
> or will we have just a node named /sys/power/check_size, if
> 1(default), check, otherwise(0 set by users), skip checking?

Or just avoid the check at all, since it no longer makes sense with
compression?

What is the failure scenario? Hibernation still fails, but it takes
longer to fail?

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

  reply	other threads:[~2011-11-18 19:02 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-04  7:36 [PATCH] PM: HIBERNATION: skip the swap size check if the snapshot image size is anticipative Barry Song
2011-11-04  7:36 ` Barry Song
2011-11-04  7:36 ` Barry Song
2011-11-04 22:29 ` Rafael J. Wysocki
2011-11-04 22:29   ` Rafael J. Wysocki
2011-11-04 22:29   ` Rafael J. Wysocki
2011-11-05  1:51   ` Barry Song
2011-11-05  1:51     ` [linux-pm] " Barry Song
2011-11-05  1:51     ` Barry Song
2011-11-05 18:22 ` Pavel Machek
2011-11-05 18:22   ` Pavel Machek
2011-11-06  3:24   ` Barry Song
2011-11-06  3:24     ` [linux-pm] " Barry Song
2011-11-06  3:24     ` Barry Song
2011-11-07  1:31     ` Barry Song
2011-11-07  1:31       ` [linux-pm] " Barry Song
2011-11-07  1:31       ` Barry Song
2011-11-18 19:02       ` Pavel Machek [this message]
2011-11-18 19:02         ` Pavel Machek
2011-11-19 11:17         ` Barry Song
2011-11-19 11:17           ` [linux-pm] " Barry Song
2011-11-19 11:17           ` Barry Song
2011-11-18 19:02       ` Pavel Machek
2011-11-05 18:22 ` Pavel Machek

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=20111118190233.GA16136@elf.ucw.cz \
    --to=pavel@ucw.cz \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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.