Patch for configurable ERTS_DE_BUSY_LIMIT

Rickard Green <>
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:// 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
> behavior.
> 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.
> -Scott

Hi Scott,

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 It 
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
Rickard Green, Erlang/OTP, Ericsson AB.

More information about the erlang-patches mailing list