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 08:36:00 +1000
From:	Nigel Cunningham <nigel@...el.suspend2.net>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
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)

Hi.

On Sat, 2007-04-14 at 00:35 +0200, Rafael J. Wysocki wrote:
> 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).

It does vary according to the amount of video memory used for DRM, if I
understand correctly.

Nigel

-
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/