Wouldn't stackable filesystems solve this rather neatly?
--
Ben Rosengart
UNIX Systems Engineer, Skunk Group
StarMedia Network, Inc.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
: Thoughts?
:
: man madvise?
:
:
:Yeah, but MADV_FREE doesn't really do what I need. I have no idea if the
:system actually did free my ram or not. I want to hang on to the data, but
:if more ram is needed, then it can be discarded, but I need to know that it
:did, so that I can recreate it.
On Thu, 23 Sep 1999, Matthew Dillon wrote:
: Thoughts?
:
: man madvise?
:
:
:Yeah, but MADV_FREE doesn't really do what I need. I have no idea if the
:system actually did free my ram or not. I want to hang on to the data, but
:if more ram is needed, then it can be discarded, but I
: until the system reuses it, at which point it reverts to zero-fill.
:
:Don't you mean MADV_FREE?
:
:-Alfred
Oops. Yes. Sorry.
MADV_DONTNEED maintains data integrity. MADV_FREE doesn't. What I
described in my last message applies to MADV_FREE.
: Thoughts?
:
: man madvise?
:
:
:Yeah, but MADV_FREE doesn't really do what I need. I have no idea if the
:system actually did free my ram or not. I want to hang on to the data, but
:if more ram is needed, then it can be discarded, but I need to know that it
:did, so that I can
Lo and behold, Kevin Day once said:
I don't think MADV_FREE is what I want, since it makes my memory go away
very quickly, *and* I have no way of knowing that the kernel did it.
You do have a way of knowing the kernel did it - your memory is
suddenly full of zeros. You don't have an
In message [EMAIL PROTECTED] Kevin Day writes:
: I'm now playing with compressed data streams. The decompression is slow, so
: I'd like to cache the *decompressed* version of these files. I end up
: allocating large amounts of ram in one process to cache the decompressed
: data. This is a
:I'm now playing with compressed data streams. The decompression is slow, so
:I'd like to cache the *decompressed* version of these files. I end up
:allocating large amounts of ram in one process to cache the decompressed
:data. This is a disavantage over the above scenario, since now the system
, and
then hitting a swap.
Later,
scott
- Original Message -
From: Matthew Dillon [EMAIL PROTECTED]
To: Kevin Day [EMAIL PROTECTED]
Cc: Kevin Day [EMAIL PROTECTED]; Daniel C. Sobral [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Thursday, September 23, 1999 9:54 AM
Subject: Re: Idea: disposable memory
Another idea might be to enhance the swapper. Using interleaved swap
across a number of SCSI disks is a poor-man's way of getting serious
disk bandwidth.
My seacrate's can do around 15MB/sec to the platter. My test machine's
swap is spread across three of them, giving me
I think what is needed is something similar to what we used to use at TFS.
A device driver that controled a large number of pages.
it had ioclts to allocate 'buffers' from these pages.
each buffer was given a handle by whichthe user process refered to it.
multiple processes could refer to them.
Kevin Day [EMAIL PROTECTED] wrote:
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.
As others have pointed out, this is almost (but not quite) the same as
madvise(MADV_FREE). I don't think there is
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
13 matches
Mail list logo
