Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20200327021058.221911-1-walken@google.com> <20200327021058.221911-5-walken@google.com>
 <d780d91f-43fa-b2ec-1a08-80013b153a56@web.de>
In-Reply-To: <d780d91f-43fa-b2ec-1a08-80013b153a56@web.de>
From:   Michel Lespinasse <walken@google.com>
Date:   Fri, 27 Mar 2020 00:44:29 -0700
Message-ID: <CANN689E-SZhv3tvYc11cNuvGwCi1V1n1ztAnLkUPGvvz7C85dQ@mail.gmail.com>
Subject: Re: [PATCH v2 04/10] mmap locking API: use coccinelle to convert
 mmap_sem rwsem call sites
To:     Markus Elfring <Markus.Elfring@web.de>
Cc:     linux-mm <linux-mm@kvack.org>, LKML <linux-kernel@vger.kernel.org>,
        Coccinelle <cocci@systeme.lip6.fr>,
        Andrew Morton <akpm@linux-foundation.org>,
        Vlastimil Babka <vbabka@suse.cz>,
        Matthew Wilcox <willy@infradead.org>,
        Liam Howlett <Liam.Howlett@oracle.com>,
        Jerome Glisse <jglisse@redhat.com>,
        Davidlohr Bueso <dave@stgolabs.net>,
        David Rientjes <rientjes@google.com>,
        Hugh Dickins <hughd@google.com>,
        Jason Gunthorpe <jgg@ziepe.ca>,
        Peter Zijlstra <peterz@infradead.org>,
        Laurent Dufour <ldufour@linux.ibm.com>,
        Ying Han <yinghan@google.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Fri, Mar 27, 2020 at 12:22 AM Markus Elfring <Markus.Elfring@web.de> wro=
te:
>
> > This change converts the existing mmap_sem rwsem calls to use the new
> > mmap locking API instead.
> >
> > The change is generated using coccinelle with the following rules:
>
> Would you like to apply only a single SmPL rule here?

I think this version of the patch is already a single rule, similar to
what you suggested ?

> > // spatch --sp-file mmap_lock_api.cocci --in-place --include-headers --=
dir .
>
> Command parameters like =E2=80=9C--jobs 8 --chunksize 1=E2=80=9D can be a=
lso helpful
> for a parallel execution of the desired software transformation.
>
> I suggest to consider another possibility for a bit of fine-tuning in the=
 shown
> SmPL script if you would eventually care for nicer run time characteristi=
cs
> for the application of such a SmPL disjunction.
> How do you think about to order the elements according to a probable
> function call frequency?

I'm not sure it matters that much, as long as it produces the correct
end result. The run takes about 25 seconds before any optimizations,
which I find very acceptable.

--=20
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.