linux-kernel - Re: Coccinelle: Checking the influence of “Grep query”

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.22.394.2010280748440.2766@hadrien>
Date:   Wed, 28 Oct 2020 07:50:22 +0100 (CET)
From:   Julia Lawall <julia.lawall@...ia.fr>
To:     Markus Elfring <Markus.Elfring@....de>
cc:     Julia Lawall <julia.lawall@...ia.fr>,
        Coccinelle <cocci@...teme.lip6.fr>,
        Gilles Muller <Gilles.Muller@...6.fr>,
        Julia Lawall <Julia.Lawall@...6.fr>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Michal Marek <michal.lkml@...kovi.net>,
        Nicolas Palix <nicolas.palix@...g.fr>,
        Sumera Priyadarsini <sylphrenadin@...il.com>,
        linux-kernel@...r.kernel.org, kernel-janitors@...r.kernel.org,
        Denis Efremov <efremov@...ux.com>
Subject: Re: Coccinelle: Checking the influence of “Grep query”



On Tue, 27 Oct 2020, Markus Elfring wrote:

> > It doesn't matter.  The purpose is just to select files that are relevent
> > for consideration.  If a file is selected for two reasons instead of one
> > reason, it doesn't matter; it's still selected.
>
> The software “git grep” probably supports also short-circuit evaluation
> for the discussed use case (because command parameters were selected in the way
> that this special functionality would not be excluded).
> https://github.com/git/git/blob/e8ab941b671da6890181aea5b5755d1d9eea24ec/grep.c#L1294
>
> Under which circumstances would potentially measurable effects become more interesting
> so that the reordering of the mentioned identifiers would be reconsidered?
>
>
> elfring@...ne:~/Projekte/Linux/next-patched> /usr/bin/time git grep --threads 4 -l -w -e 'for_each_node_by_type' -e 'for_each_matching_node_and_match' -e 'for_each_compatible_node' -e 'for_each_available_child_of_node' -e 'for_each_child_of_node' -e 'for_each_matching_node' -e 'for_each_node_by_name' -e 'for_each_node_with_property' -- '*.[ch]' > /dev/null
> 1.55user 0.74system 0:01.24elapsed 183%CPU (0avgtext+0avgdata 78760maxresident)k
> 216inputs+0outputs (3major+30006minor)pagefaults 0swaps
> elfring@...ne:~/Projekte/Linux/next-patched> /usr/bin/time git grep --threads 4 -l -w -e 'for_each_child_of_node' -e 'for_each_available_child_of_node' -e 'for_each_compatible_node' -e 'for_each_node_by_name' -e 'for_each_node_by_type' -e 'for_each_matching_node' -e 'for_each_matching_node_and_match' -e 'for_each_node_with_property' -- '*.[ch]' > /dev/null
> 1.55user 0.72system 0:01.24elapsed 183%CPU (0avgtext+0avgdata 74380maxresident)k
> 0inputs+0outputs (0major+31030minor)pagefaults 0swaps

As far as I can see, you are showing that the times are the same.  Why are
you wasting your time on this?

Although I didn't know that git grep was parallelizable, although since
the used time and the elapsed time are almost the same, maybe it doesn't
help much.

julia