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

Rong Xu via llvm-commits llvm-commits at lists.llvm.org
Mon Feb 20 13:26:35 PST 2017


On Mon, Feb 20, 2017 at 1:22 AM, Renato Golin <renato.golin at linaro.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.
>
>
> > 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 process you are talking about? The main process finishes and write the
profile without any issue.
It's the child process truncates the profiles during the profile merge.
llvm's profile is a monolithic big file and there is pretty large change of
happening.

I do think the fix the patch works fine. I can not use wait as the child
process become an orphan process after
the parent process exits.


>
>
> > 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.
>
> You need to find the source of the leek and plug it.
>
> cheers,
> --renato
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170220/3e992e48/attachment.html>


More information about the llvm-commits mailing list