Marc Espie wrote:
> reorganizing a large part of usr.bin or usr.sbin to just be one
> single variation of bsd.prog.mk with multiple progs and multiple object
> files... works just fine for, say 95% of the binaries in those directories
>
> (considering there are lots of directories with one single
On Wed, Nov 27, 2019 at 06:21:01PM +0200, Lauri Tirkkonen wrote:
> All that said I do understand if there is reluctance to merge the
> jobserver stuff since it doesn't actually help the current situation in
> most cases. Nevertheless it has been personally beneficial to me in
> identifying areas
On Wed, Nov 27 2019 17:09:09 +0100, Marc Espie wrote:
> I did experiment with something similar a while back:
>
> reorganizing a large part of usr.bin or usr.sbin to just be one
> single variation of bsd.prog.mk with multiple progs and multiple object
> files... works just fine for, say 95% of
On Wed, Nov 27, 2019 at 05:31:48PM +0200, Lauri Tirkkonen wrote:
> I'll give you some more background that I maybe should have given
> earlier already: in my hobby OS Unleashed, we use bmake and earlier did
> some (slightly hacky) modifications to subdir.mk to enable paralellizing
> jobs in
On Wed, Nov 27 2019 16:14:44 +0100, Marc Espie wrote:
> On Fri, Nov 15, 2019 at 03:29:29PM +0200, Lauri Tirkkonen wrote:
> > On Fri, Nov 15 2019 15:24:57 +0200, Lauri Tirkkonen wrote:
> > > Your points are valid and I agree with them completely. There are
> > > clearly problems with lock
On Fri, Nov 15, 2019 at 03:29:29PM +0200, Lauri Tirkkonen wrote:
> On Fri, Nov 15 2019 15:24:57 +0200, Lauri Tirkkonen wrote:
> > Your points are valid and I agree with them completely. There are
> > clearly problems with lock contention,
>
> and I should mention here that I would probably not
On Wed, Nov 27 2019 11:49:00 +0100, Marc Espie wrote:
> On Wed, Nov 27, 2019 at 12:42:48PM +0200, Lauri Tirkkonen wrote:
> > In a lesson to always proof-read *before* sending your message:
> >
> > On Wed, Nov 27 2019 12:31:51 +0200, Lauri Tirkkonen wrote:
> > > - a full release build with the
On Wed, Nov 27, 2019 at 12:42:48PM +0200, Lauri Tirkkonen wrote:
> In a lesson to always proof-read *before* sending your message:
>
> On Wed, Nov 27 2019 12:31:51 +0200, Lauri Tirkkonen wrote:
> > - a full release build with the jobserver enabled passed after
> >disabling
In a lesson to always proof-read *before* sending your message:
On Wed, Nov 27 2019 12:31:51 +0200, Lauri Tirkkonen wrote:
> - a full release build with the jobserver enabled passed after
>disabling gnu/usr.bin/binutils
this should, in fact, read "gnu/usr.bin/binutils-2.17". binutils builds
New diff, almost entirely rewritten and slightly redesigned, based on
your previous feedback as well as problems uncovered in testing. Sorry
it's taken so long; I've been a bit stingy with my spare time with
respect to this :)
Description of the design:
- the top-level make initializes
On Fri, Nov 15 2019 15:24:57 +0200, Lauri Tirkkonen wrote:
> Your points are valid and I agree with them completely. There are
> clearly problems with lock contention,
and I should mention here that I would probably not have observed the
magnitude of these problems had I not made make start more
On Fri, Nov 15 2019 14:16:44 +0100, Martin Pieuchot wrote:
> > Yes, that was my point exactly. Less jobs didn't fare any better (well,
> > it had less spin time, but took around the same real time), so the
> > conclusion I arrived at was that something in my setup was eventually
> > contending on
On 15/11/19(Fri) 15:03, Lauri Tirkkonen wrote:
> On Thu, Nov 14 2019 17:57:20 +0100, Martin Pieuchot wrote:
> > On 14/11/19(Thu) 17:30, Lauri Tirkkonen wrote:
> > > [...]
> > > The first test I made was on a beefy virtual machine under Hyper-V,
> > > with 32 vCPUs on a Threadripper 2950X. With
Hi Martin,
On Thu, Nov 14 2019 17:57:20 +0100, Martin Pieuchot wrote:
> On 14/11/19(Thu) 17:30, Lauri Tirkkonen wrote:
> > [...]
> > The first test I made was on a beefy virtual machine under Hyper-V,
> > with 32 vCPUs on a Threadripper 2950X. With and without this patch (and
> > the followup
On 14/11/19(Thu) 17:30, Lauri Tirkkonen wrote:
> [...]
> The first test I made was on a beefy virtual machine under Hyper-V,
> with 32 vCPUs on a Threadripper 2950X. With and without this patch (and
> the followup for share/mk), I did make -j32 -C /usr/src/usr.bin. The
> results were very
On Thu, Nov 14, 2019 at 05:30:34PM +0200, Lauri Tirkkonen wrote:
> > > @@ -347,10 +360,9 @@ print_errors(void)
> > > static void
> > > setup_signal(int sig)
> > > {
> > > - if (signal(sig, SIG_IGN) != SIG_IGN) {
> > > - (void)signal(sig, notice_signal);
> > > - sigaddset(, sig);
On Thu, Nov 14, 2019 at 05:30:34PM +0200, Lauri Tirkkonen wrote:
> Yeah, you're right, it reads like crap, I'll rewrite it. The gist of the
> thing is that 'expensive' heuristic is now only used to decide whether
> or not to print the failed command.
I object to that. Keep the "expensive"
Hi,
thanks for your comments. More responses inline, but I'd like to mention
up front that further testing I've made agrees with you; this isn't
ready by any means. I observed one hang I've yet to debug (very bad),
and the speedups weren't that great in some cases either (more on that
later).
I
On Tue, Nov 05, 2019 at 03:22:08PM +, Lauri Tirkkonen wrote:
> Hi,
>
> make has the concept of 'expensive' jobs: if the command line includes
> the word "make" in it, the command is considered expensive and other
> jobs are held until that job finishes. It does this to avoid exponential
>
Hi,
make has the concept of 'expensive' jobs: if the command line includes
the word "make" in it, the command is considered expensive and other
jobs are held until that job finishes. It does this to avoid exponential
behavior when parallelizing with -j.
Some other makes (eg. bmake and gmake) use
20 matches
Mail list logo
