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
| ||
|
Date: Mon, 4 Aug 2008 22:25:21 -0400 From: "John Stoffel" <john@...ffel.org> To: Hugh Dickins <hugh@...itas.com> Cc: Keith Packard <keithp@...thp.com>, Nick Piggin <nickpiggin@...oo.com.au>, Christoph Hellwig <hch@...radead.org>, Eric Anholt <eric@...olt.net>, linux-kernel@...r.kernel.org Subject: Re: [PATCH] Export shmem_file_setup and shmem_getpage for DRM-GEM >>>>> "Hugh" == Hugh Dickins <hugh@...itas.com> writes: Hugh> On Mon, 4 Aug 2008, Keith Packard wrote: >> On Mon, 2008-08-04 at 19:39 +0100, Hugh Dickins wrote: >> > For how long are these objects' pages pinned in memory like this? >> >> Forever? The only reason an object would get unpinned would be on >> eviction from the GTT, and objects will only be evicted if we fill the >> aperture with other stuff. When we add a register_shrinker callback, >> we'll also unpin pages at that point. >> >> A busy system should have the GTT entirely full, and that will be >> somewhere between 256MB and 1GB. Hugh> Okay, thanks for the warning. It sounds like the shrinker will Hugh> be important, but we'll also need to mark those pages as Hugh> unevictable while they're unshrunk. What about the onboard memory of graphics cards? Isn't that where Textures and such are stored as well? So once something is loaded to the card, shouldn't you be able to free it in system memory? Or swap it out ahead of time? Hugh> (Usually when drivers grab a large number of pages, they're not Hugh> on any LRU to begin with: you're being nice by choosing Hugh> swappable LRU pages - in the tmpfs case - but enough to upset Hugh> the balance while they're not swappable.) Offhand I can't say Hugh> what will be the appropriate way to do that, it's something we Hugh> need to revisit later (from your point of view it should amount Hugh> to one function call or flag set somewhere, not any grand Hugh> redesign). I just wonder here, since GPUs are different from other drivers in that (I assume) they are written too much more often than they are read to, that they should hopefully be much more amenable to drop behind semantics for pages they've been sent, to free system resources. Now I admit I am most probably smoking something which is clouding my understanding, so feel free to ingore my comments. John -- 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