Re: [HACKERS] mmap and MAP_ANON
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] mmap and MAP_ANON |
Дата | |
Msg-id | 199805131802.OAA23134@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] mmap and MAP_ANON (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
> > "G�ran Thyni" <goran@bildbasen.se> writes: > > Linux can only MAP_SHARED if the file is a *real* file, > > devices or trick like MAP_ANON does only work with MAP_PRIVATE. > > Well, this makes some sense: MAP_SHARED implies that the shared memory > will also be accessible to independently started processes, and > to do that you have to have an openable filename to refer to the > data segment by. > > MAP_PRIVATE will *not* work for our purposes: according to my copy > of mmap(2): Right. > so privately mapped segments are useless for interprocess communication, > even after we get rid of exec(). Yep. > > mmaping /dev/zero, as has been suggested earlier in this thread, > seems like a really bad idea to me. Would that not imply that > any process anywhere in the system that also decides to mmap /dev/zero > would get its hands on the Postgres shared memory segment? You > can't restrict permissions on /dev/zero to prevent it. Good point. > > Am I right in thinking that the contents of the shared memory segment > do not need to outlive a particular postmaster run? (If they do, then > we have to mmap a real file anyway.) If so, then MAP_ANON(YMOUS) is > a reasonable solution on systems that support it. On those that > don't support it, we will have to mmap a real file owned by (and only > readable/writable by) the postgres user. Time for another configure > test. MAP_ANON is the best, because it can be restricted to only postmaster children. The problem with using a real file is that the filesystem is going to be flushing those dirty pages to disk, and that could really hurt performance. Actually, when I install Informix, I always have to modify the kernel to allow a larger amount of SYSV shared memory. Maybe we just need to give people per-OS instructions on how to do that. Under BSD/OS, I now have 32MB of shared memory, or 3900 8k shared buffers. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
В списке pgsql-hackers по дате отправления: