[mpich-discuss] Controlling MPICH busy-wait behavior

[Jeff Hammond]

I wrote an example of an interposition library that inserts usleep or
nanosleep calls at microsecond granularity to blocking MPI operations. I
have done minimal testing and not in the relevant circumstances
(load-imbalance) so take it with a huge grain of salt.  The intent is to be
educational.

https://github.com/jeffhammond/NiceWait

Jeff

On Thu, Jun 4, 2020 at 8:38 AM Jeff Hammond <jeff.science at gmail.com> wrote:

> You might be able to implement this across the board using
> https://github.com/LLNL/wrap and interposing all calls to MPI_Wait
> transparently rather than changing the application code.
>
> Jeff
>
> On Thu, Jun 4, 2020 at 8:30 AM Mccall, Kurt E. (MSFC-EV41) via discuss <
> discuss at mpich.org> wrote:
>
>> Thanks Hui.  I will use MPI_Iprobe + MPI_Test.
>>
>>
>>
>> Kurt
>>
>>
>>
>> *From:* Zhou, Hui <zhouh at anl.gov>
>> *Sent:* Thursday, June 4, 2020 10:27 AM
>> *To:* discuss at mpich.org
>> *Cc:* Mccall, Kurt E. (MSFC-EV41) <kurt.e.mccall at nasa.gov>
>> *Subject:* [EXTERNAL] Re: [mpich-discuss] Controlling MPICH busy-wait
>> behavior
>>
>>
>>
>> There is no such option for MPICH. If you configure with ch3:sock, which
>> waits for the progress with blocking `poll`, I think it will not hog the
>> CPU by default, for other configurations, it always busy waits.
>>
>> Is using MPI_Iprobe + MPI_Test an option for you? If your process can
>> afford latency, then you can control your own sleep cycles between
>> MPI_Test. If MPICH will implement such non-busy-wait option, internally it
>> will just do the same test-sleep cycles.
>>
>>
>>
>> --
>> Hui Zhou
>>
>>
>>
>>
>>
>> *From: *"Mccall, Kurt E. (MSFC-EV41) via discuss" <discuss at mpich.org>
>> *Reply-To: *"discuss at mpich.org" <discuss at mpich.org>
>> *Date: *Wednesday, June 3, 2020 at 3:57 PM
>> *To: *"discuss at mpich.org" <discuss at mpich.org>
>> *Cc: *"Mccall, Kurt E. (MSFC-EV41)" <kurt.e.mccall at nasa.gov>
>> *Subject: *[mpich-discuss] Controlling MPICH busy-wait behavior
>>
>>
>>
>> Is there a means to tell MPICH to yield to other processes when
>> performing a busy-wait for incoming messages?   The page below
>> distinguishes between “aggressive busy-wait” and “degraded busy-wait”,
>> where the latter is what I’d like to try.
>>
>>
>>
>>
>> https://stackoverflow.com/questions/14560714/probe-seems-to-consume-the-cpu/14562840#14562840
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__stackoverflow.com_questions_14560714_probe-2Dseems-2Dto-2Dconsume-2Dthe-2Dcpu_14562840-2314562840&d=DwMGaQ&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=6cP1IfXu3IZOHSDh_vBqciYiIh4uuVgs1MSi5K7l5fQ&m=stZqd9Fs3P0zmm4350zML37qvC5jT4e9jhayHaxrcbw&s=auPT9hTHN3AOIqD0_f-gKxki1W12bFbMF-6s6AGIL_w&e=>
>>
>>
>>
>>
>>
>> Thanks,
>>
>> Kurt
>>
>>
>> _______________________________________________
>> discuss mailing list     discuss at mpich.org
>> To manage subscription options or unsubscribe:
>> https://lists.mpich.org/mailman/listinfo/discuss
>>
>
>
> --
> Jeff Hammond
> jeff.science at gmail.com
> http://jeffhammond.github.io/
>


-- 
Jeff Hammond
jeff.science at gmail.com
http://jeffhammond.github.io/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpich.org/pipermail/discuss/attachments/20200608/4d752f05/attachment.html>