[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
lkcl at lkcl dot net
[Bug ld/22831] ld causes massive thrashing if object files are not fully memory-resident: new algorithm needed
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:
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
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.