Skip site navigation (1) Skip section navigation (2)

Re: Posix Shared Mem patch

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com>
Subject: Re: Posix Shared Mem patch
Date: 2012-07-03 15:43:14
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Tue, Jul 3, 2012 at 5:36 PM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> On Wednesday, June 27, 2012 05:28:14 AM Robert Haas wrote:
>> On Tue, Jun 26, 2012 at 6:25 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> > Josh Berkus <josh(at)agliodbs(dot)com> writes:
>> >> So let's fix the 80% case with something we feel confident in, and then
>> >> revisit the no-sysv interlock as a separate patch.  That way if we can't
>> >> fix the interlock issues, we still have a reduced-shmem version of
>> >> Postgres.
>> >
>> > Yes.  Insisting that we have the whole change in one patch is a good way
>> > to prevent any forward progress from happening.  As Alvaro noted, there
>> > are plenty of issues to resolve without trying to change the interlock
>> > mechanism at the same time.
>> So, here's a patch.  Instead of using POSIX shmem, I just took the
>> expedient of using mmap() to map a block of MAP_SHARED|MAP_ANONYMOUS
>> memory.  The sysv shm is still allocated, but it's just a copy of
>> PGShmemHeader; the "real" shared memory is the anonymous block.  This
>> won't work if EXEC_BACKEND is defined so it just falls back on
>> straight sysv shm in that case.
>> There are obviously some portability issues here - this is documented
>> not to work on Linux <= 2.4, but it's not clear whether it fails with
>> some suitable error code or just pretends to work and does the wrong
>> thing.  I tested that it does compile and work on both Linux 3.2.6 and
>> MacOS X 10.6.8.  And the comments probably need work and... who knows
>> what else is wrong.  But, thoughts?
> Btw, RhodiumToad/Andrew Gierth on irc talked about a reason why sysv shared
> memory might be advantageous on some platforms. E.g. on freebsd there is the
> kern.ipc.shm_use_phys setting which prevents paging out shared memory and also
> seems to make tlb translation cheaper. There does not seem to exist an
> alternative for anonymous mmap.
> So maybe we should make that a config option?

Interesting to see that FreeBSD does this - while at the same time
refusing to fix the use of sysv shared memory under their own jails
system (afaik, at least). They seem to be quite undecided on if it's a
feature to remove or a feature to expand on :O Not sure I'd trust that
to stick around...

 Magnus Hagander

In response to

pgsql-hackers by date

Next:From: Robert HaasDate: 2012-07-03 15:44:13
Subject: Re: Incorrect behaviour when using a GiST index on points
Previous:From: Robert HaasDate: 2012-07-03 15:42:29
Subject: Re: Posix Shared Mem patch

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group