From owner-freebsd-hackers Wed Sep 22 20:46:19 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from celery.dragondata.com (celery.dragondata.com [205.253.12.6]) by hub.freebsd.org (Postfix) with ESMTP id F15BF154CC for ; Wed, 22 Sep 1999 20:46:17 -0700 (PDT) (envelope-from toasty@celery.dragondata.com) Received: (from toasty@localhost) by celery.dragondata.com (8.9.3/8.9.3) id WAA10857 for hackers@freebsd.org; Wed, 22 Sep 1999 22:46:39 -0500 (CDT) (envelope-from toasty) From: Kevin Day Message-Id: <199909230346.WAA10857@celery.dragondata.com> Subject: Idea: disposable memory To: hackers@freebsd.org Date: Wed, 22 Sep 1999 22:46:39 -0500 (CDT) X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Perhaps this is already possible somehow, but... In working with a graphical based embedded system (non-xwin), I'll typically mmap the graphic files and bcopy them straight to our hardware blitter. This works very nicely, since the kernel caches what it can off the disk, but when more ram is needed by other processes, things get thrown away and can be retrieved easily. I've been experimenting with various kinds of compression. Most of them decompress somewhat quickly, but it still takes time. So, I'd like to decompress them once, and put them in ram, in case I'd ever like them again. This has the side effect of sucking too much ram at times, and not using enough ram as a cache in other times. I don't know if another process springs up suddenly and needs half my system ram for a short time. The system will throw away anything in the disk cache, but will instead swap out the ram being used as a cache. Swapping the much larger decompressed data out, then bringing it back is about 4 times slower than just throwing it away, and re-reading the compressed data and decompressing it again. I'd like a way to be able to specify that a region of malloc'ed data is 'disposable' and has approximately the same weight as disk cached data. (I don't even mind running some syscall to tell the vm system that i just used a page, to update a lru counter or something). If the system needs ram back for some other process, either give me a way of knowing this when it steals the ram back, or signal me with something and tell me how much ram you want me to give back and let the userland process do it. Is anyone aware of anything even similar to this now, or can anyone think of a better way of doing this? Yes, I could make my cache smarter, but without constantly watching what other processes are doing, I could be not using ram that I could be using as a texture cache, or I might be using so much ram that my cache gets swapped out, which is much slower than me just recreating what's in the cache. Thoughts? Kevin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message