<tt><font size=2>Hi,</font></tt>
<br><tt><font size=2><br>
> I don't think you can rely on the scheduler alone if there are, say
<br>
> ten producers giving work to one consumer asynchronously.  Using
<br>
> gen_server:call from the producer to the consumer could help here?<br>
</font></tt>
<br><tt><font size=2>Indeed, using synchronous operations (not necessarily
involving OTP) between the producer(s) and the consumer(s) would balance
the processings, at the expense of many more messages being sent. We could
imagine sending one "ack" from the consumer(s) only every P messages
received (a bit like a TCP window), but the logic would then be more complex
to manage.   </font></tt>
<br>
<br><tt><font size=2>On the other hand, if the scheduler could "naturally"
slow down parts of the chain to make the work of loaded processes easier,
this would be neat. This is a bit surprising that, even with a reduction
count reduced by the number of messages in the receivers message queue
multiplied by four, producers are still scheduled at least relatively often.
Maybe the VM prefers to keep all cores busy even if it results in having
low priority processes keeping on feeding already loaded processes. Maybe
it shouldn't, especially if prefering stability over efficiency! (i.e.
priority #1: do not saturate loaded processes; then only, priority #2:
try to use all cores)         </font></tt>
<br>
<br><tt><font size=2>Best,</font></tt>
<br>
<br><tt><font size=2>Olivier.</font></tt>
<br>
<br><tt><font size=2><br>
> Cheers<br>
> <br>
> Andy<br>
> <br>
> On 21/11/2014 12:23, Olivier BOUDEVILLE wrote:</font></tt>
<br><tt><font size=2>> Hi, <br>
> <br>
> The reciprocal case (M producers and N consumers, with M >>
N) may <br>
> also be a problem. <br>
> <br>
> I can share a simple program which seems to show that the <br>
> retaliation upon the producers is at least in some cases (where M
is<br>
> the number of cores of the machine minus 1, and N=1) insufficient:
<br>
> the program will crash and burn, exhausting the memory because of
<br>
> the mailbox of the consumer becoming too large. Ideally the back-<br>
> pressure would increase steadily until the mailbox of the producer
<br>
> decreases below reasonable limits. Currently, I think that the <br>
> developer has either to tune M by hand (which would depend on the
<br>
> hardware resources...), or to perform some explicit yielding (with
<br>
> timer:sleep(1) on the producers). Neither of them is very satisfactory.
<br>
> <br>
> More generally, couldn't we hope that the scheduling logic could <br>
> cope with at least most of the M producers-N consumers scenarios,
<br>
> without resorting to hints from the developer like specifying a <br>
> process flag or performing explicit yielding? Maybe (for the M >>
N <br>
> case) it is just a matter of heavier punishing (ex: ultimately <br>
> exponential) whenever the receiving mailbox becomes too large. <br>
> <br>
> Best, <br>
> <br>
> Olivier.<br>
> ---------------------------<br>
> Olivier Boudeville<br>
> <br>
> EDF R&D : 1, avenue du Général de Gaulle, 92140 Clamart, France<br>
> Département SINETICS, groupe ASICS (I2A), bureau B-226<br>
> Office : +33 1 47 65 59 58 / Mobile : +33 6 16 83 37 22 / Fax : +33
<br>
> 1 47 65 27 13 <br>
> <br>
</font></tt>
<br><tt><font size=2>> <br>
> darach@gmail.com <br>
> Envoyé par : erlang-questions-bounces@erlang.org </font></tt>
<br><tt><font size=2>> 21/11/2014 11:27 </font></tt>
<br><tt><font size=2>> <br>
> A</font></tt>
<br><tt><font size=2>> <br>
> atill@mail.com </font></tt>
<br><tt><font size=2>> <br>
> cc</font></tt>
<br><tt><font size=2>> <br>
> erlang-questions@erlang.org </font></tt>
<br><tt><font size=2>> <br>
> Objet</font></tt>
<br><tt><font size=2>> <br>
> Re: [erlang-questions] Configuring Messaging Back Pressure</font></tt>
<br><tt><font size=2>> <br>
> <br>
> <br>
> <br>
> +1 </font></tt>
<br><tt><font size=2>> On 21 Nov 2014 04:53, "Andy Till" <atill@mail.com>
wrote: <br>
> Short outline of how erts_use_sender_punish works, please comment
if<br>
> there are any errors in the description.<br>
> <br>
> erts_use_sender_punish is a flag hard coded to 1 (true), when it is
<br>
> true a process sending messages to another process will have its <br>
> reduction count reduced by the number of messages in the receivers
<br>
> message queue multiplied by four.  Sending messages to processes
<br>
> with zero messages in the queue is free in terms of reductions, but
<br>
> sending messages to load queues is very expensive and will lead the
<br>
> scheduler to context switch to another process more often.<br>
> <br>
> In the case where the the relationship between of producers and <br>
> consumers is one to one, this makes sense.  It provides back
<br>
> pressure when part of the system is loaded.<br>
> <br>
> In the case where there is one producer to many consumers, if one
<br>
> consumer gets a flood of messages and the producer is punished then
<br>
> the punishment is not only on the producer but on all other <br>
> consumers because the producer cannot create enough work for them
as<br>
> it used all of its reductions.<br>
> <br>
> This makes performance unpredictable when work cannot be spread evenly.<br>
> <br>
> Could this be made to be configurable using a process flag?<br>
> <br>
> Cheers<br>
> <br>
> Andy<br>
> <br>
> Code:<br>
> <br>
> </font></tt><a href=https://github.com/erlang/otp/blob/><tt><font size=2>https://github.com/erlang/otp/blob/</font></tt></a><tt><font size=2><br>
> a70f0ce9b34e4db61dacb8db24f9ab5671ed4c8a/erts/emulator/beam/erl_init.c#L694
<br>
> </font></tt><a href=https://github.com/erlang/otp/blob/><tt><font size=2>https://github.com/erlang/otp/blob/</font></tt></a><tt><font size=2><br>
> 682a6082159568f40615f03d12d44ee70edd14c6/erts/emulator/beam/bif.c#L2058
<br>
> </font></tt><a href=https://github.com/erlang/otp/blob/><tt><font size=2>https://github.com/erlang/otp/blob/</font></tt></a><tt><font size=2><br>
> a8e12f7168c14cc765a63a51c838d065412795d7/erts/emulator/beam/erl_message.c#L504<br>
> <br>
> Previous mentions and issues with this feature:<br>
> <br>
> </font></tt><a href="http://erlang.org/pipermail/erlang-questions/2011-July/060314.html"><tt><font size=2>http://erlang.org/pipermail/erlang-questions/2011-July/060314.html</font></tt></a><tt><font size=2><br>
> </font></tt><a href="http://erlang.org/pipermail/erlang-questions/2011-July/060042.html"><tt><font size=2>http://erlang.org/pipermail/erlang-questions/2011-July/060042.html</font></tt></a><tt><font size=2><br>
> <br>
> _______________________________________________<br>
> erlang-questions mailing list<br>
> erlang-questions@erlang.org<br>
> </font></tt><a href="http://erlang.org/mailman/listinfo/erlang-questions"><tt><font size=2>http://erlang.org/mailman/listinfo/erlang-questions</font></tt></a><tt><font size=2><br>
> _______________________________________________<br>
> erlang-questions mailing list<br>
> erlang-questions@erlang.org<br>
> </font></tt><a href="http://erlang.org/mailman/listinfo/erlang-questions"><tt><font size=2>http://erlang.org/mailman/listinfo/erlang-questions</font></tt></a><tt><font size=2><br>
</font></tt>
<br><tt><font size=2>> <br>
> Ce message et toutes les pièces jointes (ci-après le 'Message')
sont<br>
> établis à l'intention exclusive des destinataires et les <br>
> informations qui y figurent sont strictement confidentielles. Toute
<br>
> utilisation de ce Message non conforme à sa destination, toute <br>
> diffusion ou toute publication totale ou partielle, est interdite
<br>
> sauf autorisation expresse.</font></tt>
<br><tt><font size=2>> Si vous n'êtes pas le destinataire de ce Message,
il vous est <br>
> interdit de le copier, de le faire suivre, de le divulguer ou d'en
<br>
> utiliser tout ou partie. Si vous avez reçu ce Message par erreur,
<br>
> merci de le supprimer de votre système, ainsi que toutes ses copies,<br>
> et de n'en garder aucune trace sur quelque support que ce soit. Nous<br>
> vous remercions également d'en avertir immédiatement l'expéditeur
<br>
> par retour du message.</font></tt>
<br><tt><font size=2>> Il est impossible de garantir que les communications
par messagerie <br>
> électronique arrivent en temps utile, sont sécurisées ou dénuées
de <br>
> toute erreur ou virus.<br>
> ____________________________________________________</font></tt>
<br><tt><font size=2>> This message and any attachments (the 'Message')
are intended solely<br>
> for the addressees. The information contained in this Message is <br>
> confidential. Any use of information contained in this Message not
<br>
> in accord with its purpose, any dissemination or disclosure, either
<br>
> whole or partial, is prohibited except formal approval.</font></tt>
<br><tt><font size=2>> If you are not the addressee, you may not copy,
forward, disclose or<br>
> use any part of it. If you have received this message in error, <br>
> please delete it and all copies from your system and notify the <br>
> sender immediately by return message.</font></tt>
<br><tt><font size=2>> E-mail communication cannot be guaranteed to
be timely secure, error<br>
> or virus-free.</font></tt>
<br><tt><font size=2>> <br>
</font></tt>
<br><tt><font size=2>> _______________________________________________<br>
> erlang-questions mailing list<br>
> erlang-questions@erlang.org<br>
> </font></tt><a href="http://erlang.org/mailman/listinfo/erlang-questions"><tt><font size=2>http://erlang.org/mailman/listinfo/erlang-questions</font></tt></a><tt><font size=2><br>
</font></tt><p></p>

<p><br>
Ce message et toutes les pièces jointes (ci-après le 'Message') sont établis à l'intention exclusive des destinataires et les informations qui y figurent sont strictement confidentielles. Toute utilisation de ce Message non conforme à sa destination, toute diffusion ou toute publication totale ou partielle, est interdite sauf autorisation expresse.</p>

<p>Si vous n'êtes pas le destinataire de ce Message, il vous est interdit de le copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou partie. Si vous avez reçu ce Message par erreur, merci de le supprimer de votre système, ainsi que toutes ses copies, et de n'en garder aucune trace sur quelque support que ce soit. Nous vous remercions également d'en avertir immédiatement l'expéditeur par retour du message.</p>

<p>Il est impossible de garantir que les communications par messagerie électronique arrivent en temps utile, sont sécurisées ou dénuées de toute erreur ou virus.<br>
____________________________________________________</p>

<p>This message and any attachments (the 'Message') are intended solely for the addressees. The information contained in this Message is confidential. Any use of information contained in this Message not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval.</p>

<p>If you are not the addressee, you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return message.</p>

<p>E-mail communication cannot be guaranteed to be timely secure, error or virus-free.</p>