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
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
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.
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 45
ember 23, 1999 9:54 AM
Subject: Re: Idea: disposable memory
> :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 decompre
: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
:
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 disava
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
>
>
> :> > 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,
:> 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.
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 disc
:> > 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
>
> Kevin Day 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 need to know that it
did, so tha
Kevin Day wrote:
>
> Thoughts?
man madvise?
--
Daniel C. Sobral(8-DCS)
[EMAIL PROTECTED]
[EMAIL PROTECTED]
"Thus, over the years my wife and I have physically diverged. While
I have zoomed toward a crusty middle-age, she has instead clung
doggedly to the sweet b
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 nee
15 matches
Mail list logo