Page MenuHomeFreeBSD

llvm/lld: damage control threading

Authored by mjg on Apr 2 2023, 12:48 PM.
Referenced Files
Unknown Object (File)
Sun, Sep 24, 3:14 PM
Unknown Object (File)
Jul 8 2023, 5:16 PM
Unknown Object (File)
Jul 8 2023, 5:15 PM
Unknown Object (File)
Jul 8 2023, 5:14 PM
Unknown Object (File)
Jul 8 2023, 5:14 PM
Unknown Object (File)
Jul 8 2023, 5:02 PM
Unknown Object (File)
Jun 9 2023, 8:47 AM
Unknown Object (File)
May 20 2023, 12:38 AM



As the comment says:

+ Damage control threading.

+ There are no heuristics to figure out how many threads makes sense to spawn,
all while rolling with all available cores hw threads starts being detrimental
+ to performance really early.

+ Work around by putting a hard cap unless the user explicitly requested a certain amount.

+ See
for more details.

With the link above you can see I brought it upstream, but it does not seem to be considered a problem despite their own results showing the machinery does not scale(!).

The recommendation is to make sure to pass --threads=1 which given the above state should probably be default instead, requiring people to provide a different argument if they *want* threading. An alternative "If some users don’t like the default, they can create a ld.lld shell script." does not make sense either -- add fork + exec overhead only to damage control lld's feature which was supposed to improve performance.

With admission that some degree of threading ultimately does help reduce total real time, the proposed simple patch is an easy middle ground: you still get the threading which provides *some* benefit in real time reduction, but is no longer happy to eat everything past laptop scale.

Note I proposed the idea upstream but it was not considered viable.

Diff Detail

rG FreeBSD src repository
Lint Not Applicable
Tests Not Applicable

Event Timeline

mjg requested review of this revision.Apr 2 2023, 12:48 PM
mjg updated this revision to Diff 119774.
mjg edited the summary of this revision. (Show Details)

Let's do this for now, then we can talk to upstream again about putting in some sensible value.


MaxThreadCount is an int, so this cast to unsigned can go away. The one below is only because for some reason upstream has decided that ThreadsRequested is unsigned.

This revision is now accepted and ready to land.Apr 3 2023, 3:42 PM
This revision was automatically updated to reflect the committed changes.