From: ebiederm+eric@ccr.net (Eric W. Biederman)
To: Keith Morgan <kmorgan@inter-tax.com>
Cc: linux-mm@kvack.org
Subject: Re: persistent heap design advice
Date: 08 Apr 1999 20:42:58 -0500 [thread overview]
Message-ID: <m1ogkywov1.fsf@flinx.ccr.net> (raw)
In-Reply-To: "Keith Morgan"'s message of "Thu, 8 Apr 1999 12:23:36 -0500"
>>>>> "KM" == Keith Morgan <kmorgan@inter-tax.com> writes:
KM> I am interested in creating a persistent heap library and would
KM> appreciate any suggestions on how to proceed. The 'persistent heap'
KM> would be a region of virtual memory backed by a file and could be
KM> expanded or contracted.
KM> In order to build my 'persistent heap' it seems like I need a
KM> fundamental facility that isn't provided by Linux. Please correct me if
KM> I'm wrong! It would be something like mmap() ... but different. The
KM> facility call it phmap for starters) would:
What do you see missing??
You obviously need a allactor built on top of your mmaped file but
besides that I don't see anything missing.
KM> -map virtual addresses to a user-specified file
mmap MAP_SHARED
KM> -coordinate the expansion/contraction of the file and the virtual
KM> address space
ftruncate, mmap, munmap
KM> -provide ram cache [of user-specified number of pages (cache itself is
KM> nonpagable)]*
why?? mlock
KM> -provide load-on-demand of data from the file into the cache
mmap MAP_SHARED
KM> -swap LRU pages back to the file when cache full
mmap MAP_SHARED
KM> []* I'm not sure if this is the right approach. I want to avoid paging
KM> out user program/data when traversing very large 'persistent heaps'.
Assuming a large persistent heap is larger than memory you can't help
but avoiding paging your heap. Not paging other things much is to be desired of course.
An implementtion of madvise (so you can say which pages you aren't going to need for a while
and which pages you will be needing soon) is the only piece of the puzzle I see as
missing.
KM> I an interested in writing at the highest possible level to create the
KM> phmap facility. At this point my questions are very broad (I'm not
KM> looking for a cookbook, just trying to prune the search space):
Eric
--
To unsubscribe, send a message with 'unsubscribe linux-mm my@address'
in the body to majordomo@kvack.org. For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/
next prev parent reply other threads:[~1999-04-09 1:31 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-04-08 17:23 Keith Morgan
1999-04-08 22:00 ` Ingo Oeser
1999-04-09 1:42 ` Eric W. Biederman [this message]
1999-04-09 2:50 ` Kanoj Sarcar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m1ogkywov1.fsf@flinx.ccr.net \
--to=ebiederm+eric@ccr.net \
--cc=kmorgan@inter-tax.com \
--cc=linux-mm@kvack.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox