[bind10-dev] Shared memory data source ideas

[Michal 'vorner' Vaner]

Hello

On Fri, Mar 16, 2012 at 10:35:48AM -0700, JINMEI Tatuya / 神明達哉 wrote:
> We could also use an on-disk memory image (which would be mmaped).  It
> will make the initial load time effectively zero.  I was not sure if
> such an option is included in the above document.

I don't mind doing so, but I think it's the next step. If we have a data image
with relative only pointers, it is easy to dump to disk and restore later (I'm
not sure if it is better to mmap or just read into memory, the first might be
very slow on startup as it seeks a lot, while the second can read the data with
speed of 100MB/s or so and once done, we're at full speed). I don't think we
need to worry about it right now.

> In my understanding, updating an already established memory block is
> generally difficult especially when it requires a lot of additions.
> It was not clear to me from the document how we'd go about that.

That document is not really that much detailed, I guess. Anyway, I'd envision we
have actually something like 3 blocks, one for the tree nodes, one for the name
data and one for the rdata. That way, we could consider it an array and not care
about data alignment and stuff. And each block would have some amount of reserve
to it's size. Once we reach it, we either look at how many „holes“ there are in
the data (because of deletions) and try to compact it somehow first, or we
reallocate the block to a bigger one.

> Do we have one memory "block" for each zone or share a block for
> multiple zones?

I think the optimal solution would be somewhere in between. Grouping small zones
to share the same block, but not too many of them, so we don't need to copy a
lot of data on the realocation and keeping the big zones each alone.

But that are just some random thoughts.

With regards

-- 
Next sleep is scheduled after 1k lines of code

Michal 'vorner' Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20120316/340e60f6/attachment.bin>