Patch for configurable ERTS_DE_BUSY_LIMIT
Thu Aug 12 17:38:01 CEST 2010
Scott Lystig Fritchie wrote:
> Rickard Green < rickard ◎ erlang · org > wrote:
> rg> It seems reasonable to add a configuration parameter for this.
> rg> However: [...]
> Assuming I followed instructions correctly, version 2 of this new config
> knob should be available via:
> git fetch git://github.com/slfritchie/otp.git erts_de_busy_limit
> Add flag-based setting for 'erts_de_busy_limit' constant
> A prior patch to change the 'erts_de_busy_limit' constant, based on an
> environment variable, was rejected by the Ericsson OTP team because
> environment variables are no longer used for modifying the VM's
> Families of flags like "+s" are devoted to the scheduler (except for
> "+sss"), but it wasn't obvious to me where a "+"-style flag for
> 'erts_de_busy_limit' should go. So, this patch creates a new family
> of flags, prefixed with "+z", for miscellaneous VM settings.
> The full flag name is "+zerts_de_busy_limit", which goes against the
> tradition of using "+Qmbl" for adjusting some kind of "mumble mumble"
> value but "mumble mumble" is obviously too long to be useful. If
> "+zerts_de_busy_limit" is too long, then I'll leave it to the OTP team
> to create a tradition-fitting, impossible-to-remember abbreviation to
> use instead.
> I don't a functional Java compiler with the suitable Java compliance
> level, so compiling & running the test suite isn't an option for me
> yet. I've made the attempt to write a test, but I haven't executed it
> to know if it works. erlang:system_info(erts_de_busy_limit) was added
> to make a unit test possible.
> The documentation changes are terse but present. Given the lack of
> Java above, my doc-building toolchain is broken, so I don't know if
> the formatting is correct, sorry.
I've had a look at your patch, and it needs some improvements before we
can accept it.
* The patch have no effect. The variable erts_de_busy_limit isn't used
by the distribution code.
* Improve commit message (see
would also be good to get some figures on the effects of increasing the
limit (latency, throughput).
* Choose a better name than erts_de_dist_limit. It doesn't explain
anything without looking in the source code. Its hard to choose a good
name, but perhaps dist_buf_busy_limit.
* The command line argument name should be constructed similar to the
other parameters, e.g., +zdbbl (where dbbl are the first letters in each
word in dist_buf_busy_limit).
* Improve documentation (both of the command line argument and the
system_info() argument). Describe the effect, e.g., something like: A
larger buffer limit will allow processes to buffer more outgoing
messages over the distribution. When the buffer limit has been reached,
sending processes will be suspended until the buffer size has shrunk.
The buffer limit is per distribution channel. A higher limit will give
lower latency (and higher throughput?) at the expense of higher memory
* Move the testcase into erts/emulator/test/distribution_SUITE.erl
* The testcase should use test_server:start_node/test_server:stop_node
for starting and stopping nodes. There are also local implementations in
distribution_SUITE of start_node/stop_node (using the test_server
versions) which you can use.
* The testcase should test that the parameter have the desired effect.
E.g., verify that you get lots of busy_dist_port with a small value at a
certain amount of traffic, and no or fewer busy_dist_port with a large
setting and the same amount of traffic.
Rickard Green, Erlang/OTP, Ericsson AB.
More information about the erlang-patches