Re: [HACKERS] Dynamic shared memory areas

2017-01-04 Thread Peter Geoghegan
On Tue, Nov 15, 2016 at 5:31 PM, Robert Haas wrote: > I think we should develop versions of this that (1) allocate from the > main shared memory segment and (2) allocate from backend-private > memory. Per my previous benchmarking results, allocating from > backend-private

Re: [HACKERS] Dynamic shared memory areas

2016-12-05 Thread Robert Haas
On Fri, Dec 2, 2016 at 3:46 PM, Thomas Munro wrote: > Here's a patch to provide the right format string for dsa_pointer to > printf-like functions, which clears a warning coming from dsa_dump (a > debugging function) on 32 bit systems. Committed. -- Robert Haas

Re: [HACKERS] Dynamic shared memory areas

2016-12-02 Thread Thomas Munro
On Sat, Dec 3, 2016 at 9:02 AM, Robert Haas wrote: > On Fri, Dec 2, 2016 at 2:56 PM, Robert Haas wrote: >> On Fri, Dec 2, 2016 at 1:21 PM, Robert Haas wrote: >>> On Thu, Dec 1, 2016 at 6:33 AM, Thomas Munro >>>

Re: [HACKERS] Dynamic shared memory areas

2016-12-02 Thread Robert Haas
On Fri, Dec 2, 2016 at 2:56 PM, Robert Haas wrote: > On Fri, Dec 2, 2016 at 1:21 PM, Robert Haas wrote: >> On Thu, Dec 1, 2016 at 6:33 AM, Thomas Munro >> wrote: >>> Please find attached dsa-v8.patch, and also a small

Re: [HACKERS] Dynamic shared memory areas

2016-12-02 Thread Robert Haas
On Fri, Dec 2, 2016 at 1:21 PM, Robert Haas wrote: > On Thu, Dec 1, 2016 at 6:33 AM, Thomas Munro > wrote: >> Please find attached dsa-v8.patch, and also a small test module for >> running random allocate/free exercises and dumping the

Re: [HACKERS] Dynamic shared memory areas

2016-12-02 Thread Robert Haas
On Thu, Dec 1, 2016 at 6:33 AM, Thomas Munro wrote: > Please find attached dsa-v8.patch, and also a small test module for > running random allocate/free exercises and dumping the internal > allocator state. OK, I've committed the main patch. As far as

Re: [HACKERS] Dynamic shared memory areas

2016-12-02 Thread Haribabu Kommi
On Thu, Dec 1, 2016 at 10:33 PM, Thomas Munro wrote: > > Please find attached dsa-v8.patch, and also a small test module for > running random allocate/free exercises and dumping the internal > allocator state. Moved to next CF with "needs review" status.

Re: [HACKERS] Dynamic shared memory areas

2016-11-29 Thread Robert Haas
More review: + * For large objects, we just stick all of the allocations in fullness class + * 0. Since we can just return the space directly to the free page manager, + * we don't really need them on a list at all, except that if someone wants + * to bulk release everything allocated using this

Re: [HACKERS] Dynamic shared memory areas

2016-11-28 Thread Robert Haas
On Wed, Nov 23, 2016 at 7:07 AM, Thomas Munro wrote: > Those let you create an area in existing memory (in a DSM segment, > traditional inherited shmem). The in-place versions will stlll create > DSM segments on demand as required, though I suppose if you wanted to

Re: [HACKERS] Dynamic shared memory areas

2016-11-15 Thread Robert Haas
On Thu, Nov 10, 2016 at 12:37 AM, Thomas Munro wrote: > On Tue, Nov 1, 2016 at 5:06 PM, Thomas Munro > wrote: >> On Wed, Oct 5, 2016 at 11:28 PM, Thomas Munro >> wrote: >>> [dsa-v3.patch] >> >> Here is

Re: [HACKERS] Dynamic shared memory areas

2016-10-05 Thread Dilip Kumar
On Wed, Oct 5, 2016 at 3:00 AM, Thomas Munro wrote: > Here's a new version that does that. While testing this patch I found some issue, + total_size = DSA_INITIAL_SEGMENT_SIZE; + total_pages = total_size / FPM_PAGE_SIZE; + metadata_bytes = +