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: <1539095291-9926-1-git-send-email-jinpuwang@gmail.com> <20181009161336.1abf11d48a9adf40486c30eb@linux-foundation.org>
In-Reply-To: <20181009161336.1abf11d48a9adf40486c30eb@linux-foundation.org>
From:   Jinpu Wang <jinpu.wang@profitbricks.com>
Date:   Wed, 10 Oct 2018 09:33:05 +0200
Message-ID: <CAMGffEn-ojiO7+T6Y=e5V=CkowF4g05iG2cB7wv1_1f0FypwXw@mail.gmail.com>
Subject: Re: [PATCH] lib: memcmp optimization
To:     Andrew Morton <akpm@linux-foundation.org>
Cc:     Wang Jinpu <xjtuwjp@gmail.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        =?UTF-8?Q?Florian=2DEwald_M=C3=BCller?= 
        <florian-ewald.mueller@profitbricks.com>,
        linux-kernel@vger.kernel.org, jannh@google.com, x86@kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed, Oct 10, 2018 at 1:13 AM Andrew Morton <akpm@linux-foundation.org> w=
rote:
>
> On Tue,  9 Oct 2018 16:28:11 +0200 Jack Wang <xjtuwjp@gmail.com> wrote:
>
> > From: Florian-Ewald Mueller <florian-ewald.mueller@profitbricks.com>
> >
> > During testing, I have configured 128 md/raid1's and, while under
> > heavy IO, I started a check on each of them
> > (echo check > /sys/block/mdx/md/sync_action).
> >
> > The CPU utilization went through the ceiling and when looking for
> > the cause (with 'perf top'). I've discovered that ~50% of the time
> > was spend in memcmp() called from process_checks().
> >
> > With this patch applied, it drops to 4% - 10%.
>
> Which CPU architecture?  Most important architectures appear to define
> __HAVE_ARCH_MEMCMP.
x86_64 is our case, I should have documented it more clearly.
>
> > --- a/lib/string.c
> > +++ b/lib/string.c
> > @@ -852,7 +852,7 @@ EXPORT_SYMBOL(memmove);
> >   * @count: The size of the area.
> >   */
> >  #undef memcmp
> > -__visible int memcmp(const void *cs, const void *ct, size_t count)
> > +static inline int __memcmp(const void *cs, const void *ct, size_t coun=
t)
>
> What the heck does __visible do?
>
> >  {
> >       const unsigned char *su1, *su2;
> >       int res =3D 0;
> > @@ -862,6 +862,20 @@ __visible int memcmp(const void *cs, const void *c=
t, size_t count)
> >                       break;
> >       return res;
> >  }
> > +__visible int memcmp(const void *cs, const void *ct, size_t count)
> > +{
> > +     const uint64_t *l1p =3D cs;
> > +     const uint64_t *l2p =3D ct;
> > +
> > +     while (count >=3D sizeof(*l1p)) {
> > +             if (*l1p !=3D *l2p)
> > +                     return __memcmp(l1p, l2p, sizeof(*l1p));
> > +             count -=3D sizeof(*l1p);
> > +             ++l1p;
> > +             ++l2p;
> > +     }
> > +     return __memcmp(l1p, l2p, count);
> > +}
>
> This is going to do bad things if the incoming addresses aren't
> suitably aligned.
>
Right, as you said, this is easy to fix.
> Certainly, byte-at-a-time is a pretty lame implementation when the
> addresses are suitably aligned.  A fallback to the lame version when
> there is misalignment will be simple to do.  And presumably there will
> be decent benefits to whoever is actually using this code.  But I'm
> wondering who is actually using this code!
>
I found recent discussion about why x86-64 is using generic string
function here:
+cc John, x86
https://lkml.org/lkml/2018/10/3/818


--=20
Jack Wang
Linux Kernel Developer

ProfitBricks GmbH
Greifswalder Str. 207
D - 10405 Berlin

Tel:       +49 30 577 008  042
Fax:      +49 30 577 008 299
Email:    jinpu.wang@profitbricks.com
URL:      https://www.profitbricks.de

Sitz der Gesellschaft: Berlin
Registergericht: Amtsgericht Charlottenburg, HRB 125506 B
Gesch=C3=A4ftsf=C3=BChrer: Achim Weiss, Matthias Steinberg, Christoph Steff=
ens