Re: dynamically allocating chunks from shared memory

On Wed, Jul 21, 2010 at 4:33 AM, Markus Wanner <markus(at)bluegap(dot)ch> wrote:
> Okay, so I just need to grok the SLRU stuff. Thanks for clarifying.
>
> Note that I sort of /want/ to mess with shared memory. It's what I know how
> to deal with. It's how threaded programs work as well. Ya know, locks,
> conditional variables, mutexes, all those nice thing that allow you to shoot
> your foot so terribly nicely... Oh, well...

For what it's worth, I feel your pain. I think the SLRU method is
*probably* better, but I feel your pain anyway.

>> For each backend, you store one pointer to the first queued
>> message and one pointer to the last queued message.  New messages can
>> be added by making the current last message point to a newly added
>> message and updating the last message pointer for that backend.  You'd
>> need to think about the locking and reference counting carefully to
>> make sure you eventually freed up unused pages, but it seems like it
>> might be doable.
>
> I've just read through slru.c, but still don't have a clue how it could
> replace a dynamic allocator.
>
> At the moment, the creator of an imessage allocs memory, copies the payload
> there and then activates the message by appending it to the recipient's
> queue. Upon getting signaled, the recipient consumes the message by removing
> it from the queue and is obliged to release the memory the messages occupies
> after having processed it. Simple and straight forward, IMO.
>
> The queue addition and removal is clear. But how would I do the alloc/free
> part with SLRU? Its blocks are fixed size (BLCKSZ) and the API with ReadPage
> and WritePage is rather unlike a pair of alloc() and free().

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).

>> One big advantage of attacking the problem with an SLRU is that
>> there's no fixed upper limit on the amount of data that can be
>> enqueued at any given time.  You can spill to disk or whatever as
>> needed (although hopefully you won't normally do so, for performance
>> reasons).
>
> 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. 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.

> To me it rather sounds like SLRU is a candidate for using dynamically
> allocated shared memory underneath, instead of allocating a fixed amount of
> slots in advance. That would allow more efficient use of shared memory.
> (Given SLRU's ability to spill to disk, it could even be used to 'balance'
> out anomalies to some extent).

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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company