[erlang-questions] High Priority processes not handling system tasks

Maxim Fedorov dane@REDACTED
Thu Jun 14 19:38:13 CEST 2018

Maybe it’s worth having some timeout in receive loop of cpc_receive? Otherwise erts_code_purger gets completely stuck, this code_server get_server stops responding too, and it leads to problems pretty much everywhere. That said, a single high-priority process in a tight loop stops all other processes, including those of max priority.

  Maxim Fedorov

From: <rickard.erlang.org@REDACTED> on behalf of Rickard Green <rickard@REDACTED>
Date: Saturday, May 26, 2018 at 10:59
To: "erlang-questions@REDACTED" <erlang-questions@REDACTED>, Maxim Fedorov <dane@REDACTED>
Subject: Re: High Priority processes not handling system tasks

I don't know why this mail only ended up in the archive, but not in my mailbox...

> G’Day,
> Below is a chunk of code that does not look bad at a first
> glance, but…
> start() ->
>     Pid = spawn(?MODULE, high, []),
>    io:format("Starting... "),
>    erlang:check_process_code(Pid, rec),
>     io:format("collected~n").
> high() ->
>     erlang:process_flag(priority, high),
>     endless(10).
> endless(X) ->
>     endless(X+1).
> start() never returns, because check_process_code schedules a normal priority
> system task against high priority process. It seems to be logical, but leads to
> some really weird effects. For example, code:soft_purge() hangs (in
> erts_code_purger, cpc_receive), thus whole code_server gen_server hangs,
> and this paralyses almost everything (a separate issue - cpc_receive has no
> receive timeout at all, possibly stalling whole VM).
> Is it designed behaviour? I have quite a straightforward solution (patch for
> erl_process.c), but I might now understand consequences.
> Applies to R19+ (with 'new purge strategy' enabled). Older releases (eg. R16B)
> are not affected.
> Regards,
>  Maxim Fedorov

Yes this is how the process priority scheme was intentionally designed (for better or for worse). 'high' and 'max' process priority work are alway selected before lower process priority work.

Changing the behaviour of system tasks so that lower priority tasks are interleaved with 'high' and/or 'max' priority work essentially introduce intentional priority inversion.

Utilization of 'high' and 'max' priority has to be done with outmost care. Using high or max priorities on processes that hogs the cpu very likely will get you into trouble. The documentation of process_flag(priority, _) is also quite clear on this.

This question comes up every now and then. In the past we have always rejected proposals for priory tweeks like this. I'm not claiming this priority scheme is the ultimate scheme, but this is what we have and I think we should stick with it as it is or redesign it from scratch.


Rickard Green, Erlang/OTP, Ericsson AB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20180614/2d8c2c9e/attachment.htm>

More information about the erlang-questions mailing list