> On Fri, Oct 09, 1998 at 12:50:03PM -0400, Kenneth Albanowski wrote:
> > Yes, uniformly yucky. It feels like disappearing 4K pages could be of use
> > in some contexts (places where either the cached data fits easily in a 4K
> > page, or the data is continuous, and 4K chunks can be recalculated as
> > needed.) but not especially easy to use -- and also not portable. Just
> > move over to an Alpha, and you're working with 8K pages all of a sudden...
>
> See my suggestion for "unmap-on-discard" pages, that would solve this in
> a simpler way and has other useful properties (especially the ability to
> reclaim unused portions of cached objects). And no need for a VMA.
Oh, right, of course. A segfault will be generated if any portion of the
object that isn't accessible is accessed... That does presume it's cheap
to access all portions of the object that are necessary, which might not
be the case. (It would have to be some odd and huge, from which we only
need a few piece of data, we can't predict which pieces that will be, and
if none of those pieces are available, we cannot begin the transaction in
the first place.)
I'm also not particularly fond of SIGSEG, but that's not relevant.
> > Yes, the only overhead is the extra (internal) trap to turn off the
> > discardable flag, and then the syscall to turn the bit back on (if you are
> > using the memory as a cache). That should be a miniscule overhead, though.
>
> You don't need the internal trap -- check if a page is discardable when
> it's aged enough to remove it. The normal page ageing will detect "next
> touch", you just have to clear the touched/dirty bits when marking a
> page discardable.
Oh, _very_ nice. Yes, that does fit in nicely.
This does bring me back to what I said originally. Are you _sure_ that we
aren't describing some that is actually better then mmaping /dev/zero?
This discardable approach slots in so nicely that it feels like it should
be more generically useful.
-- Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/