BIND 10 #2836: update in-memory zone loading so it can work with shmem segment

BIND 10 Development do-not-reply at isc.org
Sat Mar 2 03:54:53 UTC 2013


#2836: update in-memory zone loading so it can work with shmem segment
-------------------------------------+-------------------------------------
            Reporter:  jinmei        |                        Owner:
                Type:  task          |                       Status:  new
            Priority:  medium        |                    Milestone:  New
           Component:  data source   |  Tasks
            Keywords:                |                   Resolution:
           Sensitive:  0             |                 CVSS Scoring:
         Sub-Project:  DNS           |              Defect Severity:  N/A
Estimated Difficulty:  0             |  Feature Depending on Ticket:
         Total Hours:  0             |  shared memory data source
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------
Description changed by jinmei:

Old description:

> subtask of #2830.  depend on #2831.
>
> (according to my previous experiment) Most of the current
> implementation is sufficiently generic, so this task shouldn't be that
> difficult.
>
> The only tricky point is that `MemorySegment::allocate()` may now
> require internal region extension, which could change the base address
> of the mapped space.
>
> In my experiments, I addressed this issue by recording the latest
> pointer to `zone_data_` in the memory segment with a name at the
> beginning of `ZoneDataUpdater`:
> {{{#!cpp
>         mem_sgmt_.setNamedAddress("updater_zone_data", zone_data_);
> }}}
> (type of zone_data_ has to be changed to pointer, not reference).
>
> and if `addRdataSet` failed, update the pointer from the segment:
> {{{#!cpp
>     try {
>         addRdataSet(rrset, sig_rrset);
>     } catch (const util::MemorySegment::SegmentGrown&) {
>         // If memory allocation failed due to SegmentGrown, zone_data_
> may
>         // have been invalidated due to possible memory remapping.  So we
>         // refetch the address directly from the segment.
>         zone_data_ = static_cast<ZoneData*>(
>             mem_sgmt_.getNamedAddress("updater_zone_data"));
>
>         // In theory, even the second attempt could fail, but it should
> be
>         // very unlikely in practice.  Should that ever happen we
> propagate
>         // the exception and let the application decide the next step.
>         addRdataSet(rrset, sig_rrset);
>     }
> }}}
>
> There may be some other places that need the same trick (this was the
> only case in my experiment, but I may have missed something).
>
> If there's a better way to address the issue, it doesn't have to be
> exactly this way, of course.
>
> Test this with both local and mapped segment.

New description:

 subtask of #2830.  depend on #2831.

 (according to my previous experiment) Most of the current
 implementation is sufficiently generic, so this task shouldn't be that
 difficult.

 The only tricky point is that `MemorySegment::allocate()` may now
 require internal region extension, which could change the base address
 of the mapped space.

 In my experiments, I addressed this issue by recording the latest
 pointer to `zone_data_` in the memory segment with a name at the
 beginning of `ZoneDataUpdater`:
 {{{#!cpp
         mem_sgmt_.setNamedAddress("updater_zone_data", zone_data_);
 }}}
 (type of zone_data_ has to be changed to pointer, not reference).

 and if `addRdataSet` failed, update the pointer from the segment:
 {{{#!cpp
     try {
         addRdataSet(rrset, sig_rrset);
     } catch (const util::MemorySegment::SegmentGrown&) {
         // If memory allocation failed due to SegmentGrown, zone_data_ may
         // have been invalidated due to possible memory remapping.  So we
         // refetch the address directly from the segment.
         zone_data_ = static_cast<ZoneData*>(
             mem_sgmt_.getNamedAddress("updater_zone_data"));

         // In theory, even the second attempt could fail, but it should be
         // very unlikely in practice.  Should that ever happen we
 propagate
         // the exception and let the application decide the next step.
         addRdataSet(rrset, sig_rrset);
     }
 }}}

 There may be some other places that need the same trick (this was the
 only case in my experiment, but I may have missed something).

 If there's a better way to address the issue, it doesn't have to be
 exactly this way, of course.

 Test this with both local and mapped segment.

 And also consider calling `MemorySegment::shrinkToFit()` in zone
 writer's cleanup() (for now `ZoneWriterLocal`, but I guess we'll
 cancel subclass the writer class; it would work independently from the
 memory segment type).  This will help minimize the extra memory space
 overhead after loading/replacing the zone.

--

-- 
Ticket URL: <https://bind10.isc.org/ticket/2836#comment:1>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development


More information about the bind10-tickets mailing list