[compiler-rt] r295364 - [PGO] Suspend SIGKILL for PR_SET_PDEATHSIG in profile-write

Xinliang David Li via llvm-commits llvm-commits at lists.llvm.org
Mon Feb 20 12:57:39 PST 2017


On Mon, Feb 20, 2017 at 1:22 AM, Renato Golin via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> On 17 February 2017 at 17:57, Rong Xu via llvm-commits
> <llvm-commits at lists.llvm.org> wrote:
> > Is this system very slow in file write?
>
> No, it's using a SATAII SSD disk.
>
>
The test as is written is flaky.


>
> > I think the test tries to dump the
> > profile while the child process still write the file.
> > I have a sleep(1) b/w the end of main process and profile dump. It seems
> > this is no enough.
>
> This doesn't make sense.
>
> If the process has ended it should have flushed the I/O. If the OS has
> buffered it, it won't try to access the file until it's completely
> written. If you can physically remove the disk (USB), then you need a
> sync, not a sleep.
>
>
What the test case tries to test is that profile data won't be truncated by
the child process which is not waited by its parent.  The test case is thus
explicitly written in a way that parent does not wait for the child.
However the test driver needs to wait for the child process to finish
before invoking the next command to examine the profile. Using sleep is a
flaky/no reliable way to do that.  Is there a better way do it?   The
'wait' command only works for shell's children.

David




>
> > Is it possible to get a temporal access to this machine?
> > If not, I can reduce the profile size or have a longer wait period before
> > profile dump.
>
> Neither of these solutions seem remotely helpful, as this could break
> in other machines, OSs or just less often.


That is right.

David

>
> You need to find the source of the leek and plug it.
>
> cheers,
> --renato
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170220/3bb05f10/attachment.html>


More information about the llvm-commits mailing list