Hi Robert, On 2013-12-04 23:32:27 -0500, Robert Haas wrote: > But I'm also learning painfully that this kind of thing only goes so > far. For example, I spent some time looking at what it would take to > provide a dynamic shared memory equivalent of palloc/pfree, a facility > that I feel fairly sure would attract a few fans.
I have to admit, I don't fully see the point in a real palloc() equivalent for shared memory. If you're allocating shared memory in a granular fashion at somewhat high frequency you're doing something *wrong*. And the result is not going to be scalable. > Well, for regular > palloc, we store a pointer to the memory context before the beginning > of the chunk, so that when you call pfree you can find the memory > context and stick the chunk on one of its free lists. So there are > two pointers there: the pointer to the context is a pointer, of > course, but so is the free list. Heh, heh. This is one of those times where live really, really would be easier if we were using c++. Just have small smart-pointer wrapper, and we wouldn't need to worry too much. > I still have mixed feelings about the idea of same-address mappings. > On the one hand, on 64-bit architectures, there's a huge amount of > address space available. Assuming the OS does something even vaguely > sensible in terms of laying out the text, heap, stack, and shared > library mappings, there ought to be many petabytes of address space > that never gets touched, and it's hard to see why we couldn't find > some place in there to stick our stuff. It's actually quite a bit away from petabytes. Most x86-64 CPUs have 48bit of virtual memory, with the OS eating up a far bit of that (so it doesn't need to tear down TLBs in system calls). I think cross-platform you end up with something around 8TB, up to 64TB on others OSs. Now, there are some CPUs coming out with bigger virtual memory sizes, but it's going to be longer than I am willing to wait till we are there. > Now, on the other hand, as far as dynamic shared memory allocation and > freeing is concerned, there aren't really THAT many places where I > need a pointer, so using Size or uint64 or something to store an > offset instead is annoying, but I have an idea how to do this that > only uses pointers in a couple of places, so I think it can be made to > work. I am not sure how much complaint that will provoke, though. > And even if I do it, the first poor slob that wants to store a linked > list or so in dynamic shared memory is going to be unhappy if they > can't get a same-address mapping. Maybe that's OK; using linked lists > in shared memory might not be a great idea in the first place. I'm > sure there will be more than one person who wants to do it, though. > a Just because people want it, doesn't make it worthwile to provide it ;) > Any thoughts on what the least painful compromise is here? I think a reasonable route is having some kind of smart-pointer on C level that abstracts away the offset math and allows to use pointers locally. Something like void *sptr_deref(sptr *); where the returned pointer can be used as long as it is purely in memory. And sptr_update(sptr *, void *); which allows a sptr to point elsewhere in the same segment. + lots of smarts I continue to believe that a) using pointers in dynamically allocated segments is going to end up with lots of pain. b) the pain from not having real pointers is manageable. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
