<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<div dir="auto">Ticket numbers are maintained on GitHub: https://github.com/pmodels/mpich/issues/2201
<div dir="auto"><br>
</div>
<div dir="auto">Ken</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mar 8, 2017 5:17 PM, Jeff Hammond <jeff.science@gmail.com> wrote:<br type="attribution">
<blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div dir="ltr"><br>
<div><br>
<div class="elided-text">On Wed, Mar 8, 2017 at 2:25 PM, Latham, Robert J. <span dir="ltr">
<<a href="mailto:robl@mcs.anl.gov">robl@mcs.anl.gov</a>></span> wrote:<br>
<blockquote style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex">
On Wed, 2017-03-08 at 09:25 +0000, Giuseppe Congiu wrote:<br>
> Hello Rob,<br>
> <br>
> > I'm excited to see someone using the MPIX_Grequest interface. We<br>
> > used<br>
> > the MPIX_Grequest interface to implement non-blocking collective<br>
> > I/O,<br>
> > and had some bad interactions between libc's aio and the grequest<br>
> > callbacks. I don't know if you are running into something similar.<br>
><br>
> Maybe. Do you have a description of the problem somewhere?<br>
<br>
The guy who did that work just left last Friday. I'll have to dig up<br>
the archives. Looks like it was a hard-to-debug segfault <a href="https://trac">
https://trac</a>.<br>
<a href="http://mpich.org/projects/mpich/ticket/2201">mpich.org/projects/mpich/<wbr>ticket/2201</a><br>
<br>
</blockquote>
<div><br>
</div>
<div>That link is 404. Not sure if temporary or permanent.</div>
<div><br>
</div>
<div>Jeff</div>
<div> </div>
<blockquote style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex">
> <br>
> > Do you have any desire or plans to submit these changes into<br>
> > upstream<br>
> > ROMIO? <br>
><br>
> The idea would be to push these changes to upstream ROMIO if this is<br>
> relevant for the community. <br>
<br>
I don't encounter many BeeGFS users, but ROMIO file system drivers are<br>
fairly self-contained and it wouldn't be a burden to ship with them in<br>
ROMIO.<br>
<br>
<br>
> In principle here I have the same intent. The difference is that I<br>
> cannot check on progress since<br>
> BeeGFS does not provide a way for checking the status of a single<br>
> request. Instead it only<br>
> offers a blocking wait interface for all the requests submitted for a<br>
> certain file (identified<br>
> by the filename). Thus I need to invoke deeper_cache_flush_wait()<br>
> from inside one of the<br>
> callbacks.<br>
<br>
Blocking the progress engine when it expects to repeatedly call non-<br>
blocking functions could work as long as deeper_cache_flush_wait()<br>
eventually finishes and nothing needs MPI.<br>
<br>
Now, all I know about DEEP-ER is what I just read on <a href="https://www.beegfs">
https://www.beegfs</a><br>
.com/wiki/cacheAPI, so I'm sure I don't know the whole picture, but<br>
can you call deeper_cache_flush_is_<wbr>finished() and deeper_cache_flush()<br>
without the WAIT flag? Stick those two routines in the poll_fn().<br>
<br>
The generalized request extensions provide a wait_fn() that should be<br>
able to handle this, too...<br>
<br>
When it gets stuck, what does the call stack look like?<br>
<br>
Is it stuck for good or just making progress really really slowly?<br>
<br>
==rob<br>
______________________________<wbr>_________________<br>
To manage subscription options or unsubscribe:<br>
<a href="https://lists.mpich.org/mailman/listinfo/devel">https://lists.mpich.org/<wbr>mailman/listinfo/devel</a></blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div>Jeff Hammond<br>
<a href="mailto:jeff.science@gmail.com">jeff.science@gmail.com</a><br>
<a href="http://jeffhammond.github.io/">http://jeffhammond.github.io/</a></div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</body>
</html>