[PATCH] D116367: [ELF][LTO] Call madvise(MADV_DONTNEED) on BitcodeFile buffers

Teresa Johnson via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Dec 29 13:23:00 PST 2021


tejohnson added a comment.

In D116367#3212867 <https://reviews.llvm.org/D116367#3212867>, @MaskRay wrote:

> In D116367#3212805 <https://reviews.llvm.org/D116367#3212805>, @tejohnson wrote:
>
>> In D116367#3212369 <https://reviews.llvm.org/D116367#3212369>, @MaskRay wrote:
>>
>>> This can be used by in-process LTO. I haven't tested it yet.
>>
>> Would it be better to try unconditionally marking all/only the bitcode file memory buffers as MADV_DONTNEED?
>
> (Uploaded the previous diff before seeing your comment.)
>
> Agree. Bitcode files can be completely MADV_DONTNEED even in non --thinlto-index-only mode.
> For `ELFFileBase` files, their section and symbol names are used in non --thinlto-index-only mode and nearly unused in --thinlto-index-only mode.
>
>> For the large thin link this change is very close to the same peak RSS reduction as with my change to destroy the buffer objects completely:
>> Head: 10.7G
>> Destroy: 8.9G
>> Don'tNeed: 9.1G
>>
>> However, when I tried my earlier version which unconditionally freed all the memory buffers, I found that the memory buffer name is used when creating the output indices, which I fixed by saving the name in the InputFile object. Would not doing so with this change cause a time degradation because we will need to pull all these pages back in to get the name from the buffers?
>
> The MemoryBuffer identifier is stored separated from the buffer content, so technically there should be no issue. In my coarse estimate yesterday, I haven't found any time degradation.
>
> I will benchmark this by running more times.

I tried a few times and didn't see a slowdown.

However, with the latest version to only free the bitcode files, I am seeing less memory reduction (9.3G vs 9.1G before), and also a 30-40s slowdown (maybe the DenseSet lookups?). Something could probably be done to avoid the lookups, but do you have any idea why the memory reduction would be less? Hmm, probably there are some other non-bitcode files that are being read for symbol resolution but not being used further in index only mode?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D116367/new/

https://reviews.llvm.org/D116367



More information about the llvm-commits mailing list