Re: dynamically allocating chunks from shared memory

Hi,

first of all, thanks for your feedback, I enjoy the discussion.

On 07/21/2010 07:25 PM, Robert Haas wrote:
> Given what you're trying to do, it does sound like you're going to
> need some kind of an algorithm for space management; but you'll be
> managing space within the SLRU rather than within shared_buffers.  For
> example, you might end up putting a header on each SLRU page or
> segment and using that to track the available freespace within that
> segment for messages to be read and written.  It'll probably be a bit
> more complex than the one for listen (see asyncQueueAddEntries).

But what would that buy us? Also consider that pretty much all available 
dynamic allocators use shared memory (either from the OS directly, or 
via mmap()'d area).

>> Yes, imessages shouldn't ever be spilled to disk. There naturally must be an
>> upper limit for them. (Be it total available memory, as for threaded things
>> or a given and size-constrained pool, as is the case for dynshmem).
>
> I guess experience has taught me to be wary of things that are wired
> in memory.  Under extreme memory pressure, something's got to give, or
> the whole system will croak.

I absolutely agree to that last sentence. However, experience has taught 
/me/ to be wary of things that needlessly swap to disk for hours before 
reporting any kind of error (AKA swap hell). I prefer systems that 
adjust to the OOM condition, instead of just ignoring it and falling 
back to disk (which isn't doesn't provide infinite space, so that's just 
pushing the limits).

The solution for imessages certainly isn't spilling to disk, which would 
consume even more resources. Instead the process(es) for which there are 
pending imessages should be allowed to consume them.

That's why upon OOM, IMessageCreate currently simply blocks the process 
that wants to create an imessages. And yes, that's not quite perfect 
(that process should still consume messages for itself), and it might 
not play well with other potential users of dynamically allocated 
memory. But it certainly works better than spilling to disk (and yes, I 
tested that behavior within Postgres-R).

> Consider also the contrary situation,
> where the imessages stuff is not in use (even for a short period of
> time, like a few minutes).  Then we'd really rather not still have
> memory carved out for it.

Huh? That's exactly what dynamic allocation could give you: not having 
memory carved out for stuff you currently don't need, but instead being 
able to dynamically use memory where most needed. SLRU has memory (not 
disk space) carved out for pretty much every sub-system separately, if 
I'm reading that code correctly.

> I think what would be even better is to merge the SLRU pools with the
> shared_buffer pool, so that the two can duke it out for who is in most
> need of the limited amount of memory available.

..well, just add the shared_buffer pool to the list of candidates that 
could use dynamically allocated shared memory. It would need some 
thinking about boundaries (i.e. when to spill to disk, for those modules 
that /want/ to spill to disk) and dealing with OOM situations, but 
that's about it.

Regards

Markus