Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 31 Oct 2000 07:34:16 -0500 (EST)
From:      Peter Dufault <dufault@hda.com>
To:        Matt Dillon <dillon@earth.backplane.com>
Cc:        Terry Lambert <tlambert@primenet.com>, Ryan Thompson <ryan@sasknow.com>, freebsd-hackers@FreeBSD.ORG
Subject:   Re: Filesystem holes
Message-ID:  <200010311235.HAA31834@hda.hda.com>
In-Reply-To: <200010310907.e9V97mk17233@earth.backplane.com> from Matt Dillon at "Oct 31, 2000 01:07:48 am"

next in thread | previous in thread | raw e-mail | index | archive | help
>     ...  Sparse matrixes are the big math problem
>     that benefit, but only because the solution to a sparse matrix problem
>     is not even close to random so the sparse matrix winds up still being
>     sparse all the way to the end of the solution.

I use them for bus simulations, which also are permanently sparse.
It would be nice to free up the regions when I "remove" a virtual
board, but in a check through POSIX I could find nothing defined to
behave that way either for mapped files or mapped memory objects.
Also, a write from any process would repopulate the region which
I really wouldn't want but I don't see that level of control
over mapping between unrelated processes  (Now I start thinking
about MAPFIXED to a specified virtual address and implementing funny
tricks but I don't have time to work on that).

In my case I'd be better off with shared memory objects that aren't
persistent but appear in the name space so that I don't accidentally
start copying a virtual bus file when the programs exit improperly.
In the sparse matrix calculations with no checkpointing or need to appear
in a name space I'd think the best thing would be to use VM with the matrix
initially mapped to a copy on write zero page.  I guess you can't
do that without mmap because of swap allocation.

Peter

--
Peter Dufault (dufault@hda.com)   Realtime development, Machine control,
HD Associates, Inc.               Fail-Safe systems, Agency approval


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200010311235.HAA31834>