linux-kernel - Re: [RFD] swsusp problem: Drivers allocate much memory during suspend (was: Re: 2.6.21-rc5: swsusp: Not enough free memory)

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]

Date:	Sat, 14 Apr 2007 00:35:35 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Pavel Machek <pavel@....cz>
Cc:	nigel@...el.suspend2.net, 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 00:10, Pavel Machek wrote:
> Hi!
> 
> > > > Well, it looks like someone allocated about 6000 pages after we had freed
> > > > enough memory for suspending.
> > > 
> > > We have a tunable allowance in Suspend2 for this, because fglrx
> > > allocates a lot of pages in its suspend routine if DRI is enabled. I
> > > think some other drivers do too, but fglrx is the main one I know.
> > 
> > I wasn't aware of that, thanks for the information.
> > 
> > I think this means we'll probably need to add a tunable, similar to image_size,
> > that will allow the users to specify how much spare memory they want to reserve
> > for suspending (instead of the constant PAGES_FOR_IO).  IMO we can call it
> > 'spare_memory'.
> 
> Just increase PAGES_FOR_IO. This should not be tunable.

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
the vast majority of cases.  Finally, I think it may be possible to speed up
image saving by increasing PAGES_FOR_IO without playing with the
image size and we can let the user try it (think of distro kernels that are
compiled for many different users).

Still, I'm not going to fight for that.

> > Still, this doesn't look like a real solution, because it would require the
> > users affected by this problem to experiment with suspending in order to
> > figure out how much spare memory they will need.
> 
> Exactly.
> 
> > IMO to really fix the problem, we should let the drivers that need much memory
> > for suspending allocate it _before_ the memory shrinker is called.  For this
> > purpose we can use notifiers that will be called before we start the shrinking
> > of memory.  Namely, if a driver needs to allocate substantial amount
> > of memory
> 
> Yes please. Using that notifier without leaking the memory will be
> "interesting" but if someone needs so much memory during suspend, let
> them eat their own complexity.

Okay, I'm going to prepare a patch along these lines.

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/