linux-kernel - Re: [patch] mm: pageable memory allocator (for DRM-GEM?)

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:	Thu, 25 Sep 2008 17:39:31 +0200
From:	Thomas Hellström <thomas@...gstengraphics.com>
To:	Keith Packard <keithp@...thp.com>
CC:	Nick Piggin <npiggin@...e.de>, "eric@...olt.net" <eric@...olt.net>,
	"hugh@...itas.com" <hugh@...itas.com>,
	"hch@...radead.org" <hch@...radead.org>,
	"airlied@...ux.ie" <airlied@...ux.ie>,
	"jbarnes@...tuousgeek.org" <jbarnes@...tuousgeek.org>,
	"dri-devel@...ts.sourceforge.net" <dri-devel@...ts.sourceforge.net>,
	Linux Memory Management List <linux-mm@...ck.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [patch] mm: pageable memory allocator (for DRM-GEM?)

Keith Packard wrote:
> On Thu, 2008-09-25 at 00:19 -0700, Thomas Hellström wrote:
>   
>>  If data is
>> dirtied in VRAM or the page(s) got discarded
>>  we need new pages and to set up a copy operation.
>>     
>
> Note that this can occur as a result of a suspend-to-memory transition
> at which point *all* of the objects in VRAM will need to be preserved in
> main memory, and so the pages aren't really 'freed', they just don't
> need to have valid contents, but the system should be aware that the
> space may be needed at some point in the future.
>
>   
Actually, I think the pages must be allowed to be freed, and that we 
don't put a requirement on "pageable"  to keep
swap-space slots for these pages. If we hit an OOM-condition during 
suspend-to-memory that's bad, but let's say we
required "pageable" to keep swap space slots for us, the result would 
perhaps be that another device wasn't able to suspend, or a user-space 
program was killed due to lack of swap-space prior to suspend.

I'm not really sure what's the worst situation, but my feeling is that 
we should not require swap-space to be reserved for VRAM, and abort the 
suspend operation if we hit OOM. That would, in the worst case, mean 
that people with non-UMA laptops and a too small swap partition would 
see their battery run out much quicker than they expected...

/Thomas



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