From: Stefano Brivio <sbrivio@redhat.com>
To: KuhnChris <kuhnchris+git@kuhnchris.eu>
Cc: passt-dev@passt.top, KuhnChris <kuhnchris@kuhnchris.eu>
Subject: Re: [PATCH] MAKE: Fix parallel builds; .o files; .gitignore; new makedocs
Date: Fri, 30 Jun 2023 19:16:19 +0200 [thread overview]
Message-ID: <20230630191544.34acb996@elisabeth> (raw)
In-Reply-To: <20230628140727.15750-1-kuhnchris+git@kuhnchris.eu>
Thanks for the patch, and sorry for the delay!
First off, as I was mentioning on IRC: it would help to have this as
two/three patches -- not just because it's easier to review, but also
because the Makefile changes have, I guess, a relatively high risk of
introducing some regressions, so keeping it simple for 'git bisect'
would also be a plus here.
If you want to split this in your working tree, you can do something
like:
git reset HEAD~
meaning: reset (the git state, not the file contents) to the commit
before head (~ is a shortcut for "just before"). Then 'git add' your
pieces back -- and if you have two changes to the Makefile you want to
keep separated, go with 'git add -i', which lets you add just parts.
If that's not your HEAD anymore, 'git rebase -i' to something before
this commit, and do the same git reset/git add trick, then 'git rebase
--continue'.
Another general comment (about the title): this doesn't actually fix
parallel builds... it makes builds more parallel.
Now, to the changes:
On Wed, 28 Jun 2023 16:07:28 +0200
KuhnChris <kuhnchris+git@kuhnchris.eu> wrote:
> From: KuhnChris <kuhnchris@kuhnchris.eu>
>
> ---
> .gitignore | 1 +
> Makefile | 51 +++++++++++++++++++++++++--------------------------
> makedocs.pl | 19 +++++++++++++++++++
> 3 files changed, 45 insertions(+), 26 deletions(-)
> create mode 100644 makedocs.pl
>
> diff --git a/.gitignore b/.gitignore
> index d3d0e2c..caeafa5 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -1,4 +1,5 @@
> *~
> +*.o
> /passt
> /passt.avx2
> /pasta
> diff --git a/Makefile b/Makefile
> index a5256f5..4c99771 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -100,29 +100,41 @@ else
> BIN := passt pasta qrap
> endif
>
> -all: $(BIN) $(MANPAGES) docs
> +.NOTPARALLEL: seccomp.h
> +all: seccomp.h $(BIN) $(MANPAGES) docs
> +
> +PASST_OBJS = $(PASST_SRCS:.c=.o)
> +PASST_AVX2_OBJS = $(PASST_SRCS:.c=.avx2.o)
> +OBJS = $(SRCS:.c=.o)
> +QRAP_OBJS = $(QRAP_SRCS:.c=.o)
> +AVXFLAGS += -Ofast -mavx2 -ftree-vectorize -funroll-loops
This all looks correct to me, but for some reason, on a machine
with 12 (free-ish) CPU threads, 'make -j1' takes the same time as
'make -j10', and seems to lead to the same amount of parallel gcc
processes... no idea why, yet. I would have expected actual parallelism
resulting from this.
By the way, build time (after a make clean) is the same as without this
change, with -j1 or -j10.
I know you're introducing this to avoid a full rebuild if only some
source files changed, which is an advantage in any case, but I'm
missing something...
>
> static: FLAGS += -static -DGLIBC_NO_STATIC_NSS
> -static: clean all
> +static: clean seccomp.h all
>
> seccomp.h: seccomp.sh $(PASST_SRCS) $(PASST_HEADERS)
> @ EXTRA_SYSCALLS="$(EXTRA_SYSCALLS)" ARCH="$(TARGET_ARCH)" CC="$(CC)" ./seccomp.sh $(PASST_SRCS) $(PASST_HEADERS)
>
> -passt: $(PASST_SRCS) $(HEADERS)
> - $(CC) $(FLAGS) $(CFLAGS) $(CPPFLAGS) $(PASST_SRCS) -o passt $(LDFLAGS)
> +.c.o:
> + $(CC) $(FLAGS) $(CFLAGS) $(CPPFLAGS) -c $< -o $@
> +
> +$(PASST_AVX2_OBJS): seccomp.h
> + $(CC) $(AVXFLAGS) $(FLAGS) $(CFLAGS) $(CPPFLAGS) -c $(@:.avx2.o=.c) -o $@
> +
> +passt: $(PASST_OBJS) seccomp.h
> + $(CC) $(FLAGS) $(CFLAGS) $(CPPFLAGS) $(PASST_OBJS) -o passt $(LDFLAGS)
>
> -passt.avx2: FLAGS += -Ofast -mavx2 -ftree-vectorize -funroll-loops
> -passt.avx2: $(PASST_SRCS) $(HEADERS)
> - $(CC) $(filter-out -O2,$(FLAGS)) $(CFLAGS) $(CPPFLAGS) \
> - $(PASST_SRCS) -o passt.avx2 $(LDFLAGS)
> +passt.avx2: $(PASST_AVX2_OBJS) $(HEADERS) seccomp.h
> + $(CC) $(filter-out -O2,$(FLAGS)) $(CFLAGS) $(CPPFLAGS) $(AVXFLAGS) \
> + $(PASST_AVX2_OBJS) -o passt.avx2 $(LDFLAGS)
>
> -passt.avx2: passt
> +passt.avx2: passt seccomp.h
>
> pasta.avx2 pasta.1 pasta: pasta%: passt%
> ln -sf $< $@
>
> -qrap: $(QRAP_SRCS) passt.h
> - $(CC) $(FLAGS) $(CFLAGS) $(CPPFLAGS) $(QRAP_SRCS) -o qrap $(LDFLAGS)
> +qrap: $(QRAP_OBJS) passt.h seccomp.h
> + $(CC) $(FLAGS) $(CFLAGS) $(CPPFLAGS) $(QRAP_OBJS) -o qrap $(LDFLAGS)
>
> valgrind: EXTRA_SYSCALLS += rt_sigprocmask rt_sigtimedwait rt_sigaction \
> getpid gettid kill clock_gettime mmap \
> @@ -170,21 +182,8 @@ pkgs: static
> # other way around: the web version should be obtained by adding HTML and
> # JavaScript portions to a plain Markdown, instead. However, cgit needs to use
> # a file in the git tree. Find a better way around this.
> -docs: README.md
> - @( \
> - skip=0; \
> - while read l; do \
> - case $$l in \
> - "## Demo") exit 0 ;; \
> - "<!"*) ;; \
> - "</"*) skip=1 ;; \
> - "<"*) skip=2 ;; \
> - esac; \
> - \
> - [ $$skip -eq 0 ] && echo "$$l"; \
> - [ $$skip -eq 1 ] && skip=0; \
> - done < README.md; \
> - ) > README.plain.md
> +docs:
The output is much more complete now (and the Makefile cleaner).
> + [ ! -e doc/ ]; mkdir docs; perl makedocs.pl > docs/README.plain.md
Shouldn't we (naturally) use Makefile dependencies for this? Also note
that you're moving the README.plain.md file to docs/, so you would also
need to change the install target:
cp -d README.plain.md $(DESTDIR)$(docdir)/README.md
...but, anyway, I think it would make more sense to keep the output in
the root directory (simply because README.md is already there, so one
can more easily spot the "plain" version).
>
> # Checkers currently disabled for clang-tidy:
> # - llvmlibc-restrict-system-libc-headers
> diff --git a/makedocs.pl b/makedocs.pl
> new file mode 100644
This should probably have 0755 permissions, it's an interpreted
executable after all.
> index 0000000..295e1d9
> --- /dev/null
> +++ b/makedocs.pl
This makes it sound like it does more than just stripping away the HTML
stuff. Perhaps make_plain_readme.pl, or plain_readme.pl,
strip_html.pl... something like that?
> @@ -0,0 +1,19 @@
Missing license header:
# SPDX-License-Identifier: GPL-2.0-or-later
and:
#!/usr/bin/perl
> +use strict;
> +
> +my $str = '';
> +my $regex = qr/(<[^\/].*?>.*?<\/.*?>\n?)|(<\/div>)|(<\/p>)/msp;
> +my $subst = '';
> +
> +
> +local $/=undef;
> +open FILE, '<', 'README.md' or die "Can't open file $!";
> +my $file_content = <FILE>;
> +close FILE;
> +#print "Source: $file_content\n";
> +my $result = $file_content =~ s/$regex//rg;
> +
> +my $regex2 = qr/\n[ \n]{3,}\n/msp;
> +$result = $result =~ s/$regex2/\n\n/rg;
> +
> +#print "The result of the substitution is: $result\n";
> +print "$result\n";
This looks good to me... I'm not sure if you intended to leave in those
comments, but I'm fine either way.
--
Stefano
next prev parent reply other threads:[~2023-06-30 17:16 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-28 14:07 [PATCH] MAKE: Fix parallel builds; .o files; .gitignore; new makedocs KuhnChris
2023-06-30 17:16 ` Stefano Brivio [this message]
2023-07-02 10:04 ` David Gibson
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=20230630191544.34acb996@elisabeth \
--to=sbrivio@redhat.com \
--cc=kuhnchris+git@kuhnchris.eu \
--cc=kuhnchris@kuhnchris.eu \
--cc=passt-dev@passt.top \
/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.
Code repositories for project(s) associated with this public inbox
https://passt.top/passt
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for IMAP folder(s).