GitLab now enforces expiry dates on tokens that originally had no set expiration date. Those tokens were given an expiration date of one year later. Please review your personal access tokens, project access tokens, and group access tokens to ensure you are aware of upcoming expirations. Administrators of GitLab can find more information on how to identify and mitigate interruption in our documentation.
Admin message
Self sign-up has been disabled due to increased spam activity. If you want to get access, please send an email to a project owner (preferred) or at gitlab(at)nic(dot)cz. We apologize for the inconvenience.
This patch is a proposal for speeding up AXFR of a lot of zones.
Same implementation is used for IXFR, but the speeding up is not significant due to flushing zone to journal.
valgrind reports tiny memory-leak (< 500 bytes), not solvable, mostly an issue for our integration tests
the "leaked" sructures are just pseudo-static objects for further call_rcu() invocations queue processing, see https://bugs.lttng.org/issues/991
leak is suppressed in integration tests
Origin: It has been observed with bootstrapping many (>= thousands) zones via AXFR that there is a significant delay in "consume" phase (~ 30 ms in our case). It can be workarounded by increasing the number of background-workers (raised from 1 to 10, caused doubling the delay, put the parallelism speeded it up anyway). The delay was tracked down to synchronize_rcu() in axfr_answer_finalize().
TODO: Open question is which rcu_read_lock actually makes the synchronize_rcu() routines wait and if it couldn't be removed/speed-uped/solved instead.
Suspecting the synchronize_rcu() barrier is there just for safe freeing old zone contents, this patch removes it and with the help of call_rcu (wrapped for cleaner code) makes the freeing asynchronously wait for grace period.
Zone transfer is also slowed down on flushing zone to journal.
It is important to disable immediate flushing to journal (don't set zone-file-sync: -1) for speeding up AXFR transfer.
