| Title: | DIGITAL UNIX (FORMERLY KNOWN AS DEC OSF/1) |
| Notice: | Welcome to the Digital UNIX Conference |
| Moderator: | SMURF::DENHAM |
| Created: | Thu Mar 16 1995 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 10068 |
| Total number of notes: | 35879 |
A customer of mine has a development project using ObjectStore OODB.
The way ObjectStore works on DU is that it allocates a 100mB file as a
cache and then mmaps it chunk by chunk in 8K chunks.
This causes a VM mapentry allocated for each 8k chunk.
Thus the customer had to increase the mapentries parameter in VM from
the deafault 200 to about 200000.
From an old DU Internals course I learned that those map_entries
are internally kept as a doubly-linked list.
- Is this still the case in DU V4.0B?
- What is the current implementation of mapentries.
- How much memory would they use for 200,000 of them.
Of course linear scan of a 200,000 element list each time we want
to find a memory page may not be very efficient(:-)).
I am concerned that this will kill the machine.
Apparently ObjectStore does that this way because in Solaris
VM the adjacent regions will be automatically joined and
redundant entries fried.
Any comments?
Thanks and regards,
Chris Jankowski
Melbourne Australia
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 9903.1 | SMURF::DENHAM | Digital UNIX Kernel | Wed May 21 1997 14:22 | 4 | |
Yes, map entries are a doubly linked list, but our VM also coalesces
map entries. It certainly tries to minimize the number of entries. Has
any looked at the running system to see how many entries it ends up
with? Does it really get 200000??
| |||||
| 9903.2 | More detail. | MEOC02::JANKOWSKI | Wed May 21 1997 21:31 | 16 | |
The customer has a little program that produces a list of map entries.
We see them being allocated for 8k chunks of address space.
Customer wants to allocate about 1Gb of space that way - its about
125,000. They never got that far though. The application is 32bit
and the largest area they can find is about 750MB.
I am thinking why the maps are not coalesced together.
I remember somebody saying that if MAP_PRIVATE is used the maps
will not be coalesced.
Is this true?
I have to chechk what mode do they use.
Regards,
Chris
| |||||
| 9903.3 | Additional Question... | SNOFS1::ELEFTHERIOU | Tue Jun 03 1997 01:39 | 13 | |
Hi,
In addition to what Chris has asked, is there a kernel parameter which
can be set to allow the aquisition of these pages (8192 bytes) in
multiples of page size? I have an outstanding call open for this
customer which addresses his concerns about the amount of time the
system takes to allocate this space (mmap-ing the file for cache).
Many thanks,
Harry E.
CSC-Sydney
[B51417]
| |||||