[PATCH] Use posix_fallocate instead of ftruncate.

Rui Ueyama via llvm-commits llvm-commits at lists.llvm.org
Tue Jul 19 13:17:56 PDT 2016


All filesystems I'm using now support the fallocate feature, so I have not
experienced slow down caused by emulation. So I do not have a strong
opinion -- as I said I just had a concern. If you think posix_fallocate is
the right approach, let's try it.

Please write a comment saying that we are calling posix_fallocate to get a
disk full error early.

On Tue, Jul 19, 2016 at 3:08 PM, Sean Silva <chisophugis at gmail.com> wrote:

>
>
> On Tue, Jul 19, 2016 at 1:06 PM, Rafael EspĂ­ndola <
> llvm-commits at lists.llvm.org> wrote:
>
>> > Well, is detecting a disk full event so important to risk that it could
>> slow
>> > down the linker on NFS or such? It'd depend how often you hit it, but
>> to me
>> > it doesn't feel like a good trade-off.
>>
>> I would probably say it is. If you are linking on nfs you probably
>> cannot expect any reasonable link time right now.
>>
>> If we want to support that we should resurrect my patch to link to a
>> posix_align allocated anonymous memory and then just use write to pass
>> it to the os.
>>
>
> Yeah, this sounds like the right approach. AFAIK nobody has tested LLD on
> NFS and so any behaviors/perf we have there are going to be purely
> accidental. Also IIRC mmap on NFS has issues? And we rely on mmap heavily
> on the input side too.
>
> -- Sean Silva
>
>
>>
>> In any case, lets benchmark it before we start adding more #ifdefs and
>> options.
>>
>> The attached patch uses a cmake check to avoid making things worse
>> (but not any better) on systems that don't have posix_fallocate.
>>
>> What do you want me to benchmark? Linking the current benchmarks on
>> NFS? Is linux as the server OK?
>>
>> Cheers,
>> Rafael
>>
>> _______________________________________________
>> 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/20160719/4199dbf1/attachment.html>


More information about the llvm-commits mailing list