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: <200704141133.33366.rjw@sisk.pl>
Date:	Sat, 14 Apr 2007 11:33:32 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Nigel Cunningham <nigel@...el.suspend2.net>
Cc:	Pavel Machek <pavel@....cz>, Jiri Slaby <jirislaby@...il.com>,
	Linux kernel mailing list <linux-kernel@...r.kernel.org>,
	linux-pm@...ts.osdl.org
Subject: Re: [RFD] swsusp problem: Drivers allocate much memory during suspend (was: Re: 2.6.21-rc5: swsusp: Not enough free memory)

On Saturday, 14 April 2007 01:03, Nigel Cunningham wrote:
> Hi.
> 
> On Sat, 2007-04-14 at 00:57 +0200, Rafael J. Wysocki wrote:
> > > > > Well, I'm not sure.  First, we don't really know what the value of it should be
> > > > > and this alone is a good enough reason for making it tunable, IMHO.  Second, I
> > > > > think different systems may need different PAGES_FOR_IO and taking just the
> > > > > maximum (even if we learn how much that actually is) seems to be wasteful in
> > > > 
> > > > Well,  it is wasteful as in "we save slightly smaller image than we
> > > > could". That's okay with me.
> > > 
> > > No. If the driver can't allocate the memory, your call to device_suspend
> > > will fail. This isn't about image size but about success or failure to
> > > hibernate.
> > 
> > If we take PAGES_FOR_IO to be the maximum over all possible configurations
> > that can hibernate, the majority of systems will just create smaller images than
> > they could have created for smaller PAGES_FOR_IO, but all of them will be
> > able to hibernate. :-)
> 
> You also use PAGES_FOR_IO in enough_free_mem. Say you set it to the 9000
> pages I mentioned before (35M). On a machine with 64 megabytes of
> memory, you'll never be able to suspend because you'll never satisfy
> 
> free > nr_pages + PAGES_FOR_IO + meta

Well, in fact our tunable would need to be independent of PAGES_FOR_IO so that
the memory shrinker could free some spare memory for the drivers.

> I'll freely admit that 64 megabytes is tiny nowadays, but it's not
> completely unknown. The point is really that you're effectively making
> swsusp unusable for machines with RAM < (PAGES_FOR_IO * (say) 3). But
> what do you set PAGES_FOR_IO to? There'll always be someone with
> $WHIZ_BANG_CONFIG who is pushing to have the value increased, and every
> increase knocks out more of your lowend users.

Yes, that's why I said I wasn't sure whether or not the additional tunable was
needed.

Still, with the notifiers we have a chance to handle the problem automatically
and the tunable would require the user to set the right value.

Greetings,
Rafael
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ