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