From: Thomas Renninger <trenn@suse.com>
To: Ivan Babrou <ivan@cloudflare.com>
Cc: linux-pm@vger.kernel.org,
linux-kernel <linux-kernel@vger.kernel.org>,
kernel-team <kernel-team@cloudflare.com>,
Shuah Khan <shuah@kernel.org>
Subject: Re: [PATCH] cpupower: add Makefile dependencies for install targets
Date: Thu, 07 Jan 2021 21:59:51 +0100 [thread overview]
Message-ID: <3977966.bfq5YHlNPR@c100> (raw)
In-Reply-To: <CABWYdi0sne=6reP5oZMFbYk9Nctws=FLoYkjdmnBwXu0bVFozA@mail.gmail.com>
Am Donnerstag, 7. Januar 2021, 18:42:25 CET schrieb Ivan Babrou:
> On Thu, Jan 7, 2021 at 2:07 AM Thomas Renninger <trenn@suse.com> wrote:
> > Am Dienstag, 5. Januar 2021, 00:57:18 CET schrieb Ivan Babrou:
> > > This allows building cpupower in parallel rather than serially.
> >
> > cpupower is built serially:
> >
> > [ make clean ]
> >
> > time make
> > real 0m3,742s
> > user 0m3,330s
> > sys 0m1,105s
> >
> > [ make clean ]
> >
> > time make -j10
> > real 0m1,045s
> > user 0m3,153s
> > sys 0m1,037s
> >
> > Only advantage I see is that you can call
> > make install-xy
> > targets without calling the corresponding build target
> > make xy
> > similar to the general install target:
> > install: all install-lib ...
> >
> > Not sure anyone needs this and whether all targets
> > successfully work this way.
> > If you'd show a useful usecase example...
>
> We build a bunch of kernel related tools (perf, cpupower, bpftool,
> etc.) from our own top level Makefile, propagating parallelism
> downwards like one should.
I still do not understand why you do not simply build:
Also if I call this from /tools directory I get a quick build:
make -j20 cpupower
Can you please show the make calls, ideally with a timing to better understand
and also to reproduce the advantages this patch introduces.
From what I can see, it only helps if one calls "sub-install" targets
directly?
And I still do not understand why things should be more parallel now.
> Without this patch we have to remove parallelism for cpupower,
Why?
> which doesn't seem like a very clean thing
> to do, especially if you consider that it's 3x faster with parallelism
> enabled in wall clock terms.
Sure, you want to build in parallel. I still do not understand how this
patch helps in this regard.
BTW, I recently had a bunch of userspace tools Makefile patches.
I'd like to add you to CC for a review if they are not submitted already.
Thomas
next prev parent reply other threads:[~2021-01-07 21:00 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-04 23:57 [PATCH] cpupower: add Makefile dependencies for install targets Ivan Babrou
2021-01-07 10:07 ` Thomas Renninger
2021-01-07 17:42 ` Ivan Babrou
2021-01-07 20:59 ` Thomas Renninger [this message]
2021-01-07 21:15 ` Ivan Babrou
2021-01-07 21:29 ` Thomas Renninger
2021-01-22 18:02 ` Shuah Khan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3977966.bfq5YHlNPR@c100 \
--to=trenn@suse.com \
--cc=ivan@cloudflare.com \
--cc=kernel-team@cloudflare.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=shuah@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox