[bind10-dev] Multicore Auth

[JINMEI Tatuya / 神明達哉]

At Tue, 12 Jul 2011 23:52:06 +0200,
Michal 'vorner' Vaner <michal.vaner at nic.cz> wrote:

> I believe all of those could be implemented and serve our purpose. The question
> is, what of them look like simplest to you and what do you like? We probably
> should decide before we start implementing it. Or should this discussion be
> moved to some future sprint?

Overall your analysis seems reasonable.  Here are my comments:

- 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?

  (forgetting this big question for now...)

- I would first begin with 'multi process, separate in-memory data
  source', then 'multi process, shared in-memory data source'.  I
  suspect the overall memory footprint won't be a serious concern for
  BIND 10 so soon, so I'd prefer simplicity, stability, and gradual
  improvements.  In particular, the separate model would make the
  update implementation much simpler.

- I'd point out multi thread would not be as bad as we might think for
  authoritative only servers (with relatively stable zones).  It would
  be quite possible to rely on giant (and read-write) locks
  for the entire zone, and it doesn't involve heavy synchronization
  overhead.  That said, I'd still prefer multi process approach,
  because it would be more flexible (for example, it would be easier
  to run multiple processes with different configurations).  Also, we
  may hit other inter thread contention with multiple threads such as
  that within boost or ASIO.  And, even if we can use cheaper locks,
  locking still involves costs, and if we want to scale up to several
  tens of cores, the total costs may become non-negligible.

- For update support, I like the two copy approach Stephen mentioned.

- (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.

- 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.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.