[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACKH++aCPZEwMwreYS7492qabmcj14NWbv9QE6Tp=WN09kE=1w@mail.gmail.com>
Date: Fri, 29 Nov 2024 16:25:09 +0900
From: Rui Ueyama <rui314@...il.com>
To: наб <nabijaczleweli@...ijaczleweli.xyz>
Cc: LKML <linux-kernel@...r.kernel.org>
Subject: Re: Wislist for Linux from the mold linker's POV
On Fri, Nov 29, 2024 at 4:17 PM наб <nabijaczleweli@...ijaczleweli.xyz> wrote:
>
> Hi! one quick q to clarify, if you don't mind.
>
> On Thu, Nov 28, 2024 at 11:52:35AM +0900, Rui Ueyama wrote:
> > - exit(2) takes a few hundred milliseconds for a large process
> >
> > I believe this is because mold mmaps all input files and an output
> > file, and clearing/flushing memory-mapped data is fairly expensive.
> >
> > To avoid this overhead, mold currently forks a child process, lets the
> > child handle the actual linking task, and then, as soon as the child
> > closes the output file, the parent exits (which takes no time since
> > the parent is lightweight). Since the child is not an interactive
> > process, it can afford to take its time for exit. While this works, I
> > would prefer to avoid it if possible, as it is somewhat a hacky
> > workaround.
> Sooo am I reading it right that the output file is not valid when mold exits,
> since you seem to be exiting /during/ exit->munmap->msync,
> while the contents of the file are undefined,
> so mold -o whatever && ./whatever is not valid
> (while mold -o whatever then ./whatever later is)?
No worries. The child mold process unmaps and closes an output file
before notifying the parent mold process of completion. Therefore, the
output file is guaranteed to be complete and valid when the parent
exits.
Powered by blists - more mailing lists