[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug ld/22831] ld causes massive thrashing if object files are not fully

From: lkcl at lkcl dot net
Subject: [Bug ld/22831] ld causes massive thrashing if object files are not fully memory-resident: new algorithm needed
Date: Fri, 21 Dec 2018 19:54:43 +0000


--- Comment #19 from Luke Kenneth Casson Leighton <lkcl at lkcl dot net> ---
(In reply to H.J. Lu from comment #18)
> (In reply to Luke Kenneth Casson Leighton from comment #17)
> > https://issues.guix.info/issue/33676
> > 
> > so we have a successful report that the advised option helps.
> > 
> Have you tried my users/hjl/pr18028 branch?

 as i mentioned before, i (personally) do not have the resources
 to try anything out: i am acting as a go-between, to find people
 who *can* try out different branches.

 i took a look at the diffs:


 some comments:

 bfd/linker.c line 3492 - i see what's going on.  this is great,
 it *in principle* makes sure that the amount of memory used is
 not exceeded.

 bfd/linker.c line 3484 - this is completely arbitrary.  this is
 NOT repeat NOT, as i have already said, and repeat, NOT limited
 to 32 bit.  64-bit systems ALSO HAVE THE EXACT SAME PROBLEM.
 this test needs to be removed.

 ld/ldmain.c: line 275 - specifying half the memory is arbitrary.

 so, as i said: it is not enough.  what if the amount of memory
 used by other programs exceeeds half the available memory?

 conditions where that will occur immediately: make -j2.

 one ld process will take half the memory

 the other ld process will take half the memory.

 now BOTH processes will enter thrashing.

 as i said, right in the original report: it is necessary to DYNAMICALLY
 check the amount of available memory, just like gcc does.

 in that way, ld will remain DYNAMICALLY under the limit, it will STAY
 in resident memory.

 ld must be prevented from going into swap space, at all costs, basically.

You are receiving this mail because:
You are on the CC list for the bug.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]