I've gotten fairly far into compiling and running dovecot on HPUX. The
problem I'm currently having is that the index seems to be mmap'ed at
twice after login. The 576 byte mmap is the index file:
root at hp46t243 # grep mmap64 /tmp/dovecot.tusc
[imap ][1707] mmap64(NULL, 576, PROT_READ|PROT_WRITE, MAP_SHARED,
7, 0) = 0xc166c000
[imap ][1707] mmap64(NULL, 18432, PROT_READ, MAP_SHARED, 8, 0)
........ = 0xc166d000
[imap ][1707] mmap64(NULL, 24, PROT_READ, MAP_SHARED, 9, 0)
........... = 0xc1672000
[imap ][1707] mmap64(NULL, 576, PROT_READ|PROT_WRITE, MAP_SHARED,
7, 0) ERR#12 ENOMEM
[imap ][1717] mmap64(NULL, 576, PROT_READ|PROT_WRITE, MAP_SHARED,
7, 0) = 0xc166c000
[imap ][1717] mmap64(NULL, 18432, PROT_READ, MAP_SHARED, 9, 0)
........ = 0xc166d000
[imap ][1717] mmap64(NULL, 24, PROT_READ, MAP_SHARED, 8, 0)
........... = 0xc1672000
[imap ][1717] mmap64(NULL, 576, PROT_READ|PROT_WRITE, MAP_SHARED,
7, 0) ERR#12 ENOMEM
[imap ][1897] mmap64(NULL, 576, PROT_READ|PROT_WRITE, MAP_SHARED,
7, 0) = 0xc166c000
[imap ][1897] mmap64(NULL, 18432, PROT_READ, MAP_SHARED, 9, 0)
........ = 0xc166d000
[imap ][1897] mmap64(NULL, 24, PROT_READ, MAP_SHARED, 8, 0)
........... = 0xc1672000
[imap ][1897] mmap64(NULL, 576, PROT_READ|PROT_WRITE, MAP_SHARED,
7, 0) ERR#12 ENOMEM
[imap ][2042] mmap64(NULL, 576, PROT_READ|PROT_WRITE, MAP_SHARED,
7, 0) = 0xc166c000
[imap ][2042] mmap64(NULL, 18432, PROT_READ, MAP_SHARED, 9, 0)
........ = 0xc166d000
[imap ][2042] mmap64(NULL, 24, PROT_READ, MAP_SHARED, 8, 0)
........... = 0xc1672000
[imap ][2042] mmap64(NULL, 576, PROT_READ|PROT_WRITE, MAP_SHARED,
7, 0) ERR#12 ENOMEM
[imap ][2178] mmap64(NULL, 576, PROT_READ|PROT_WRITE, MAP_SHARED,
7, 0) = 0xc166c000
[imap ][2178] mmap64(NULL, 18432, PROT_READ, MAP_SHARED, 9, 0)
........ = 0xc166d000
[imap ][2178] mmap64(NULL, 24, PROT_READ, MAP_SHARED, 8, 0)
........... = 0xc1672000
[imap ][2178] mmap64(NULL, 576, PROT_READ|PROT_WRITE, MAP_SHARED,
7, 0) ERR#12 ENOMEM
[imap ][2318] mmap64(NULL, 576, PROT_READ|PROT_WRITE, MAP_SHARED,
7, 0) = 0xc166c000
[imap ][2318] mmap64(NULL, 18432, PROT_READ, MAP_SHARED, 9, 0)
........ = 0xc166d000
[imap ][2318] mmap64(NULL, 24, PROT_READ, MAP_SHARED, 8, 0)
........... = 0xc1672000
[imap ][2318] mmap64(NULL, 576, PROT_READ|PROT_WRITE, MAP_SHARED,
7, 0) ERR#12 ENOMEM
root at hp46t243 #
I think multiple mmap's of the same file are verboten --
+ In most cases, two separate calls to mmap() cannot map
overlapping ranges in a file. The virtual address range
reserved for a file range is determined at the time of the
initial mapping of the file range into a process address
space. The system allocates only the virtual address range
necessary to represent the initial mapping. As long as the
initial mapping exists, subsequent attempts to map a different
file range that includes any portion of the initial range may
fail with an ENOMEM error if an extended contiguous address
range that preserves the mappings of the initial range cannot
be allocated.
So, I was trying to look at why the index file is being mapped twice,
and why the addr isn't saved and reused. I was thinking of adding it to
one of the index structures and skipping the mmap if the addr != 0.
I've been poking around for a couple of hours today and am going to call
it a day, but I thought I'd ping the list to see if there was something
obvious I was missing.
Rich
On Fri, 2006-06-23 at 16:13 -0700, Rich Rauenzahn wrote:> I think multiple mmap's of the same file are verboten -- > > + In most cases, two separate calls to mmap() cannot map > overlapping ranges in a file. The virtual address range > reserved for a file range is determined at the time of the > initial mapping of the file range into a process address > space. The system allocates only the virtual address range > necessary to represent the initial mapping. As long as the > initial mapping exists, subsequent attempts to map a different > file range that includes any portion of the initial range may > fail with an ENOMEM error if an extended contiguous address > range that preserves the mappings of the initial range cannot > be allocated.Well, I don't see anything like that described in Linux or UNIX98 man pages..> So, I was trying to look at why the index file is being mapped twice, > and why the addr isn't saved and reused.The problem has something to do with how index file code works internally. A "view" is (supposed to be) a snapshot of the mailbox at a given state. It's not updated until the view is synchronized. Each view points to a "map" which contains the index file's mmap pointer and other information, including records_count which tells how many messages it holds. mail_index_map() is used to get the latest mapping of the index file. If the existing latest map is already used by views, Dovecot simply discards the existing map and mmap()s the file all over again. One way to handle this would be to unmap the existing area always, mmap() it and update all the existing maps' pointer to the new one. But since the maps may have different files mmapped (the index file could have been rebuilt and the maps point to different files), it's not that simple to implement. Another workaround would be to move the map to memory and let the views use that. That would be pretty easy to implement, but if HP-UX is the only OS where this breaks, I think I'll just leave it as it is since it's faster this way.. Anyway, I think something like this should fix it (not tested): diff -u -r1.230.2.5 mail-index.c --- src/lib-index/mail-index.c 17 Jun 2006 13:42:36 -0000 1.230.2.5 +++ src/lib-index/mail-index.c 24 Jun 2006 19:35:30 -0000 @@ -1031,6 +1031,15 @@ /* this map is already used by some views and they may have pointers into it. leave them and create a new mapping. */ if (!index->mmap_disable) { + struct mail_index_map *old_map; + + old_map = index->map; + map = mail_index_map_clone(index->map, + index->map->hdr.record_size); + map->refcount = index->map->refcount; + mail_index_unmap(index, &index->map); + *old_map = *map; + i_free(map); map = NULL; } else { /* create a copy of the mapping instead so we don't -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20060624/b6c13b5b/attachment.bin>