[bind10-dev] Multicore Auth

[Michal 'vorner' Vaner]

Hello

On Thu, Jul 14, 2011 at 06:15:06PM -0700, JINMEI Tatuya / 神明達哉 wrote:
> - One key question is how often we want to be able to reflect changes.
>   If we want to support, say, 1000 dynamic updates / sec and want to
>   make the changes visible "instantly", I can hardly imagine any other
>   approach than multi threads + locking (there may be a clever way to
>   achieve the goal with, e.g., shared memory + multiple processes,
>   still involving very few synchronization overhead, but I have no
>   specific idea right now).  If we can allow some delay in propagating
>   changes so that we can apply a set of changes at once and
>   periodically (e.g., every 30sec), other approaches such as multi
>   process + shared memory image can be a solution.  Do we have any
>   specific goal/requirement regarding this question?

Well, as far as I looked, it is possible to have not only shared memory, but
shared mutexes and locks. That way we can have separate processes and still
propagate pretty fast by locking in some kind of shared memory.

Also, as Evan noted, if we have a big mostly stable area and small „journal“,
this can propagate changes fast as well.

> - (Assuming performance is the major reason for supporting multi
>   cores) I think we should keep in our mind implications with multi
>   cores, but I suspect the development should be deferred until we
>   support all major basic features (at least: full DNSSEC support for
>   in-memory data source, dynamic update and IXFR) and we sufficiently
>   improve single-core case.

I just happened to notice we have it in our plan for current 3-sprint ;-)

> - Another thing to be considered is how/whether to share hot spot
>   cache between instances (threads/processes) running on different
>   cores.  I've not fully thought about that, but I suspect we'd end up
>   each instance having separate cache.  That would lead to increase
>   total memory footprint, which may or may not be a big issue.  If
>   it's substantial, we need to consider a nice way to deal with that.

I think this is the same or similar problem as the in-memory. If it turns out to
be too much memory and too little sharing, we could put it into shared memory
somehow. Maybe misusing the in-memory datasource once it can live in shared
memory would be easier than porting the current (slower) cache.

With regards

-- 
Work with computer has 2 phases. First, computer waits for the user to tell it what 
to do, then the user waits for the computer to do it. Therefore, computer work 
consists mostly of waiting.

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/20110715/4a493f66/attachment.bin>