From: Shreenidhi Shedi <yesshedi@gmail.com>
To: Masahiro Yamada <masahiroy@kernel.org>
Cc: dhowells@redhat.com, dwmw2@infradead.org,
gregkh@linuxfoundation.org, nathan@kernel.org,
ndesaulniers@google.com, nicolas@fjasle.eu,
linux-kernel@vger.kernel.org, sshedi@vmware.com
Subject: Re: [PATCH v7 8/8] kbuild: modinst: do modules_install step by step
Date: Wed, 9 Aug 2023 22:57:40 +0530 [thread overview]
Message-ID: <d59d98e3-d43d-44fb-a07e-1bae70447ee2@gmail.com> (raw)
In-Reply-To: <CAK7LNASR1fCXG8M-3=Zb-_i2mFFt-cHpREzeWkw1Fe-Zuz_XSw@mail.gmail.com>
On 08/08/23 00:14, Masahiro Yamada wrote:
> On Mon, Aug 7, 2023 at 5:08 PM Shreenidhi Shedi <yesshedi@gmail.com> wrote:
>>
>> On 07/08/23 01:02, Masahiro Yamada wrote:
>>> On Fri, Jun 23, 2023 at 11:54 PM Shreenidhi Shedi <yesshedi@gmail.com> wrote:
>>>>
>>>> Currently Makefile.modinst does three tasks on each module built:
>>>> - Install modules
>>>> - Sign modules
>>>> - Compress modules
>>>>
>>>> All the above tasks happen from a single place.
>>>>
>>>> This patch divides this task further and uses a different makefile for
>>>> each task.
>>>> Signing module logic is completely refactored and everything happens
>>>> from a shell script now.
>>>>
>>>> Signed-off-by: Shreenidhi Shedi <yesshedi@gmail.com>
>>>
>>>
>>> This patch is bad in multiple ways.
>>>
>>> 1. Break "make modules_sign"
>>
>> Correct, somehow I missed it. I will fix it.
>> I'm using below command to test sign only option. Please let me know if
>> I should use something else.
>>
>> make modules_sign modules_sign_only=1 INSTALL_MOD_PATH=$PWD/tmp -j8
>>
>>> 2. Serialize the installation steps, that is, works less efficiently
>>
>> Even in the existing system it happens in serially.
>
> The existing code runs in parallel.
>
> 1. Copy the module "foo.ko" to the destination
> 2. Sign the module "bar.ko"
> 3. Compress the module "baz.ko"
>
> Those three have no dependency among them, so
> should be able to run in parallel.
>
> Your code serializes 1 -> 2 -> 3
>
>
>
>> And the existing
>> method takes more time than the proposed version.
>>
>> root@ph5dev:~/linux-6.3.5 # ./test.sh orig
>>
>> real 0m14.699s
>> user 0m55.519s
>> sys 0m9.036s
>>
>> root@ph5dev:~/linux-6.3.5 # ./test.sh new
>>
>> real 0m13.327s
>> user 0m46.885s
>> sys 0m6.770s
>>
>> Here is my test script.
>> ```
>> #!/bin/bash
>>
>> set -e
>>
>> if [ "$1" != "new" ] && [ "$1" != "orig" ]; then
>> echo "invalid arg, ($0 [orig|new])" >&2
>> exit 1
>> fi
>>
>> rm -rf $PWD/tmp
>>
>> s="scripts/sign-file.c"
>> m="scripts/Makefile.modinst"
>> fns=($s $m)
>>
>> for f in ${fns[@]}; do
>> cp $f.$1 $f
>> done
>>
>> cd scripts
>> gcc -o sign-file sign-file.c -lcrypto
>> cd -
>>
>> time make modules_install INSTALL_MOD_PATH=$PWD/tmp -s -j$(nproc)
>> ```
>>
>>> 3. Increase code without adding any benefits.
>>> Agree with increased code but this change is one step closer to Unix
>> philosophy, do one thing well wrt modules_install.
>
>
> I do not understand why "closer to Unix philosophy"?
>
> You are adding extra/unnecessary complexity.
>
> Currently, the parallel job is managed by Make's job server.
>
> You are introducing another way of parallel execution
> in scripts/signfile.sh
> (and you completely ignored -j <jobs> option to Make,
> and always spawned $(nproc) threads).
>
>
> Leave the parallel execution GNU Make.
> That is how Kbuild works _properly_.
>
>
>
>
>>> There is no good reason to do these chang >I hope the data I provided above to your 2nd point provides evidence
>> that this fix is improving existing system. Please take a look again.
>
>
> I saw it. I re-confirmed this is not an improvement. Thanks for the data.
>
> As I replied to the other thread, my measurement did not show an
> attractive result.
> https://lore.kernel.org/lkml/CAK7LNATNRchNoj0Y6sdb+_81xwV3kAX57-w5q2zew-q8RyzJVg@mail.gmail.com/T/#m8234fc76e631363fbe6bdfb6e45ef6727fc48e80
>
>
>>
>>> NACK.
>>
>> Hi Masahiro Yamada,
>>
>> Replies inline above.
>>
>> Please correct me if my understanding is wrong. Thanks a lot for your
>> time and patience. Have a nice time ahead.
>
>
> I must let you know you are misunderstanding
> the meaning of NACK.
>
>
> NACK means:
> "I do not like it. Please do not submit it any more".
>
>
>
> --
> Best Regards
> Masahiro Yamada
Thanks for all the advice and your time, I'm getting used to this
process. I dropped Kbuild changes from my patch series v9. PTAL.
Have a nice time ahead.
--
Shedi
prev parent reply other threads:[~2023-08-09 17:27 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-23 14:53 [PATCH v7 0/8] refactor file signing program Shreenidhi Shedi
2023-06-23 14:53 ` [PATCH v7 1/8] sign-file: use getopt_long_only for parsing input args Shreenidhi Shedi
2023-06-23 14:53 ` [PATCH v7 2/8] sign-file: inntroduce few new flags to make argument processing easy Shreenidhi Shedi
2023-08-07 2:35 ` Masahiro Yamada
2023-08-07 7:57 ` Shreenidhi Shedi
2023-06-23 14:53 ` [PATCH v7 3/8] sign-file: move file signing logic to its own function Shreenidhi Shedi
2023-06-23 14:53 ` [PATCH v7 4/8] sign-file: add support to sign modules in bulk Shreenidhi Shedi
2023-06-23 14:53 ` [PATCH v7 5/8] sign-file: improve help message Shreenidhi Shedi
2023-06-23 14:53 ` [PATCH v7 6/8] sign-file: use const with a global string constant Shreenidhi Shedi
2023-06-23 14:53 ` [PATCH v7 7/8] sign-file: fix do while styling issue Shreenidhi Shedi
2023-06-23 14:53 ` [PATCH v7 8/8] kbuild: modinst: do modules_install step by step Shreenidhi Shedi
2023-08-04 14:06 ` Greg KH
2023-08-05 19:00 ` Shreenidhi Shedi
2023-08-06 6:45 ` Greg KH
2023-08-07 11:18 ` Shreenidhi Shedi
2023-08-06 19:32 ` Masahiro Yamada
2023-08-07 8:08 ` Shreenidhi Shedi
2023-08-07 18:44 ` Masahiro Yamada
2023-08-09 17:27 ` Shreenidhi Shedi [this message]
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=d59d98e3-d43d-44fb-a07e-1bae70447ee2@gmail.com \
--to=yesshedi@gmail.com \
--cc=dhowells@redhat.com \
--cc=dwmw2@infradead.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=masahiroy@kernel.org \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=nicolas@fjasle.eu \
--cc=sshedi@vmware.com \
/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