Re: Dynamic shared memory areas

On Wed, Oct 5, 2016 at 10:04 PM, Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
> On Wed, Oct 5, 2016 at 3:00 AM, Thomas Munro
> <thomas(dot)munro(at)enterprisedb(dot)com> 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 =
> + MAXALIGN(sizeof(dsa_area_control)) +
> + MAXALIGN(sizeof(FreePageManager)) +
> + total_pages * sizeof(dsa_pointer);
> + /* Add padding up to next page boundary. */
> + if (metadata_bytes % FPM_PAGE_SIZE != 0)
> + metadata_bytes += FPM_PAGE_SIZE - (metadata_bytes % FPM_PAGE_SIZE);
> + usable_pages =
> + (total_size - metadata_bytes) / FPM_PAGE_SIZE;
>
> + segment = dsm_create(total_size, 0);
> + dsm_pin_segment(segment);
>
> Actually problem is that size of dsa_area_control is bigger than
> DSA_INITIAL_SEGMENT_SIZE.
> but we are allocating segment of DSA_INITIAL_SEGMENT_SIZE size.
>
> (gdb) p sizeof(dsa_area_control)
> $8 = 67111000
> (gdb) p DSA_INITIAL_SEGMENT_SIZE
> $9 = 1048576
>
> In dsa-v1 problem was not exist because DSA_MAX_SEGMENTS was 1024,
> but in dsa-v2 I think it's calculated wrongly.
>
> (gdb) p DSA_MAX_SEGMENTS
> $10 = 16777216

Oops, right, thanks. A last minute change to that macro definition
that I stupidly tested only in USE_SMALL_DSA_POINTER mode. Here is a
fix for that, capping DSA_MAX_SEGMENTS as before.

--
Thomas Munro
http://www.enterprisedb.com