From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vk0-f66.google.com (mail-vk0-f66.google.com [209.85.213.66]) by mail.openembedded.org (Postfix) with ESMTP id 6D05A75518 for ; Thu, 14 Jun 2018 21:49:02 +0000 (UTC) Received: by mail-vk0-f66.google.com with SMTP id b77-v6so4588198vkb.5 for ; Thu, 14 Jun 2018 14:49:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WwxhfHq6oPFmXEby2SwQj1c7mhU0bosVsEMKBniVJaY=; b=XJM150QdWPbHmwj6suHz1hDaQJ4LzApM4UInuDRe5kv78YUlXxl8j3OuJAfF9GjtYZ iQsPihNcJp8pEQ4duJWzKcS17kTKSY03RMGBIwlAOHgY2dOJHmcg3PpsYgfqUdrGp/0k Y73Zr7pD/EH3Il4v4CJ7z0csjE5/X7VK7q4qQjjlZFGuuj0wxbRTjhCnwAFYMqAWcX+S tOkPg9LHMHh6P7lkkAVdI/7n9YYRn+mj0Xh/ycWVd+E22JRp3z0AwEqgVWU3oR0OKdmp uCE+ZFsx5CwVyEh1r5IrD1pwGaDL6q3Tg2oYd9m5KRO/hn5uah4xC7BG640UEg1/MYXB 6tXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WwxhfHq6oPFmXEby2SwQj1c7mhU0bosVsEMKBniVJaY=; b=H65kJuHdaaXkTqHhmXnOivcrtsGkkTVL0SBHDdc5loVJYIcEwehuwZrDyMhP8oqVY0 DBEHDwop88PHZRsN+mmmSjXZWAnhsdbQeka46SNwAALmFUFRCsjPTG58vkT9romrmBZg I/YwISI/zsn0FAcPZSfb/+Es9/vLzrSV2sSkabq4g4RNCDjBCBs4BA8E43+figGRlljX vZnrhFlG+lO//eanVuej12dcQ8UicAaHzsYXqiw4vAM3IenGr8pPibIkHlTT3JlzJxLq uaFdGO/OaduOUjKTfgkCYabXBpnEmOE/AfeWzJDzQ+wivACtqKWDsQsTx0sGG4DoDXfQ 2fzQ== X-Gm-Message-State: APt69E24mDTKPPL4vBkp2MLCwK/77qjTCzrZJBEMAIrqTOCT3DsVVy2l ditb7IaoGVm/Ee6I2hV4fwpn2ukPJs7Z3BJIl/c= X-Google-Smtp-Source: ADUXVKKZZKquv6bbzdbth+zsbj1YHpGsbHDlxs7SfogtkZVZ5yVuSB1j06urhMurDF0GcMgfZqg2JMj1+jZBS/WPID8= X-Received: by 2002:a1f:4b86:: with SMTP id y128-v6mr2576040vka.146.1529012943060; Thu, 14 Jun 2018 14:49:03 -0700 (PDT) MIME-Version: 1.0 References: <1528977321-8121-1-git-send-email-ovidiu.panait@windriver.com> <002e01d403d8$b811f1b0$2835d510$@neuf.fr> <20da1542-9903-d4fc-b38f-8f0ad3b2d4a1@gmail.com> In-Reply-To: From: Khem Raj Date: Thu, 14 Jun 2018 14:48:51 -0700 Message-ID: To: Andre McCurdy Cc: Patches and discussions about the oe-core layer Subject: Re: [PATCH 1/1] db: disable the ARM assembler mutex code X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 21:49:02 -0000 Content-Type: multipart/alternative; boundary="00000000000054063d056ea1113f" --00000000000054063d056ea1113f Content-Type: text/plain; charset="UTF-8" On Thu, Jun 14, 2018 at 1:01 PM Andre McCurdy wrote: > On Thu, Jun 14, 2018 at 12:24 PM, Khem Raj wrote: > > On Thu, Jun 14, 2018 at 12:12 PM Andre McCurdy > wrote: > >> > >> On Thu, Jun 14, 2018 at 9:40 AM, Khem Raj wrote: > >> > On 6/14/18 5:10 AM, Herve Jourdain wrote: > >> >> Hi, > >> >> > >> >> I believe I solved that same problem by just adding, in the case of > armv8 > >> >> (which I believe may be the new architecture you're referring to): > >> >> MUTEX_armv8 = "" > >> >> This way, it allows previous versions to work just like they did > before, > >> >> without having to disable ARM assembler mutex code for architectures > that > >> >> support it correctly - up to armv7ve I believe. > >> >> Of course, we might need to also have a good definition for armv8, > which is > >> >> the object of another thread. > >> > > >> > right thats a better approach. > >> > >> SWP is not guaranteed to work on SMP systems... and even if it does, > >> performance is likely to be worse than the pthreads version (which can > >> take advantage of the newer instructions). > >> > >> > https://community.arm.com/processors/b/blog/posts/locks-swps-and-two-smoking-barriers > >> > >> In general, use of hand optimised assembler mutex implementations in > >> user space isn't something to be encouraged - use pthreads (or maybe a > >> gcc intrinsic) instead. > >> > > > > question is about disabling it on old arm machines, do we have data where > > we know that other sync methods without swp works better on armv5 and > lower ? > > On armv5 and below a hand optimised implementation using SWP is likely > to be faster than pthreads. No one is suggesting otherwise. > > On SMP (highly likely nowadays for armv7 and above), SWP simply might > not work (aside from the fact that if it does work, it's likely to be > slower than pthreads). It's not really a question of performance > there, so the proposal to only disable SWP for armv8 doesn't seem like > a safe solution. > Suggestion is not to just do it for armv8 but To keep it there where its beneficial > > Using pthreads unconditionally is safe and easy. Unless you can prove > that hand optimised SWP is really a big win for armv5 (is anyone > really running a performance critical database on an armv5 system?) > why not keep the recipe simple and use pthreads everywhere? > > >> I think the original patch is good. > >> > >> >> Cheers, > >> >> Herve > >> >> > >> >> -----Original Message----- > >> >> From: openembedded-core-bounces@lists.openembedded.org > >> >> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf > Of > >> >> Ovidiu Panait > >> >> Sent: jeudi 14 juin 2018 13:55 > >> >> To: openembedded-core@lists.openembedded.org > >> >> Subject: [OE-core] [PATCH 1/1] db: disable the ARM assembler mutex > code > >> >> > >> >> The swpb in macro MUTEX_SET will cause "undefined instruction" error > on the > >> >> new arm arches which don't support this assembly instruction any > more. If > >> >> use ldrex/strex to replace swpb, the old arm arches don't support > them. So > >> >> to avoid this issue, just disable the ARM assembler mutex code, and > use the > >> >> default pthreads mutex. > >> >> > >> >> Signed-off-by: Li Zhou > >> >> Signed-off-by: Catalin Enache > >> >> Signed-off-by: Ovidiu Panait > >> >> --- > >> >> meta/recipes-support/db/db_5.3.28.bb | 13 +------------ > >> >> 1 file changed, 1 insertion(+), 12 deletions(-) > >> >> > >> >> diff --git a/meta/recipes-support/db/db_5.3.28.bb > >> >> b/meta/recipes-support/db/db_5.3.28.bb > >> >> index 093ee44909..15b4155a29 100644 > >> >> --- a/meta/recipes-support/db/db_5.3.28.bb > >> >> +++ b/meta/recipes-support/db/db_5.3.28.bb > >> >> @@ -59,18 +59,7 @@ FILES_SOLIBSDEV = "${libdir}/libdb.so > >> >> ${libdir}/libdb_cxx.so" > >> >> # All the --disable-* options replace --enable-smallbuild, which > breaks a > >> >> bunch of stuff (eg. postfix) DB5_CONFIG ?= "--enable-o_direct > >> >> --disable-cryptography --disable-queue --disable-replication > >> >> --disable-verify --disable-compat185 --disable-sql" > >> >> > >> >> -EXTRA_OECONF = "${DB5_CONFIG} --enable-shared --enable-cxx > --with-sysroot" > >> >> - > >> >> -# Override the MUTEX setting here, the POSIX library is -# the > default - > >> >> "POSIX/pthreads/library". > >> >> -# Don't ignore the nice SWP instruction on the ARM: > >> >> -# These enable the ARM assembler mutex code, this won't -# work > with thumb > >> >> compilation... > >> >> -ARM_MUTEX = "--with-mutex=ARM/gcc-assembly" > >> >> -MUTEX = "" > >> >> -MUTEX_arm = "${ARM_MUTEX}" > >> >> -MUTEX_armeb = "${ARM_MUTEX}" > >> >> -EXTRA_OECONF += "${MUTEX} STRIP=true" > >> >> +EXTRA_OECONF = "${DB5_CONFIG} --enable-shared --enable-cxx > --with-sysroot > >> >> STRIP=true" > >> >> EXTRA_OEMAKE += "LIBTOOL='./${HOST_SYS}-libtool'" > >> >> > >> >> EXTRA_AUTORECONF += "--exclude=autoheader -I ${S}/dist/aclocal > >> >> -I${S}/dist/aclocal_java" > >> >> -- > >> >> 2.17.1 > >> >> > >> >> -- > >> >> _______________________________________________ > >> >> Openembedded-core mailing list > >> >> Openembedded-core@lists.openembedded.org > >> >> http://lists.openembedded.org/mailman/listinfo/openembedded-core > >> >> > >> > > >> > > >> > > >> > -- > >> > _______________________________________________ > >> > Openembedded-core mailing list > >> > Openembedded-core@lists.openembedded.org > >> > http://lists.openembedded.org/mailman/listinfo/openembedded-core > >> > > --00000000000054063d056ea1113f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu= , Jun 14, 2018 at 1:01 PM Andre McCurdy <armccurdy@gmail.com> wrote:
On Thu, Jun 14, 2018 at 12:24 PM, Khem Raj <raj.khem@gmail.com> wrote:
> On Thu, Jun 14, 2018 at 12:12 PM Andre McCurdy <armccurdy@gmail.com> wrote: >>
>> On Thu, Jun 14, 2018 at 9:40 AM, Khem Raj <raj.khem@gmail.com> wrote:
>> > On 6/14/18 5:10 AM, Herve Jourdain wrote:
>> >> Hi,
>> >>
>> >> I believe I solved that same problem by just adding, in t= he case of armv8
>> >> (which I believe may be the new architecture you're r= eferring to):
>> >> MUTEX_armv8 =3D ""
>> >> This way, it allows previous versions to work just like t= hey did before,
>> >> without having to disable ARM assembler mutex code for ar= chitectures that
>> >> support it correctly - up to armv7ve I believe.
>> >> Of course, we might need to also have a good definition f= or armv8, which is
>> >> the object of another thread.
>> >
>> > right thats a better approach.
>>
>> SWP is not guaranteed to work on SMP systems... and even if it doe= s,
>> performance is likely to be worse than the pthreads version (which= can
>> take advantage of the newer instructions).
>>
>>=C2=A0 =C2=A0https://community.arm.com/processors/b/blog/posts/locks-swps-and-two-= smoking-barriers
>>
>> In general, use of hand optimised assembler mutex implementations = in
>> user space isn't something to be encouraged - use pthreads (or= maybe a
>> gcc intrinsic) instead.
>>
>
> question is about disabling it on old arm machines, do we have data wh= ere
> we know that other sync methods without swp works better on armv5 and = lower ?

On armv5 and below a hand optimised implementation using SWP is likely
to be faster than pthreads. No one is suggesting otherwise.

On SMP (highly likely nowadays for armv7 and above), SWP simply might
not work (aside from the fact that if it does work, it's likely to be slower than pthreads). It's not really a question of performance
there, so the proposal to only disable SWP for armv8 doesn't seem like<= br> a safe solution.

Suggestion is no= t to just do it for armv8 but
To keep it there where= its beneficial=C2=A0

Using pthreads unconditionally is safe and easy. Unless you can prove
that hand optimised SWP is really a big win for armv5 (is anyone
really running a performance critical database on an armv5 system?)
why not keep the recipe simple and use pthreads everywhere?

>> I think the original patch is good.
>>
>> >> Cheers,
>> >> Herve
>> >>
>> >> -----Original Message-----
>> >> From: openembedded-core-bounces@lists.openembe= dded.org
>> >> [mailto:openembedded-core-bounces@lists.openem= bedded.org] On Behalf Of
>> >> Ovidiu Panait
>> >> Sent: jeudi 14 juin 2018 13:55
>> >> To: openembedded-core@lists.openembedded.org
>> >> Subject: [OE-core] [PATCH 1/1] db: disable the ARM assemb= ler mutex code
>> >>
>> >> The swpb in macro MUTEX_SET will cause "undefined in= struction" error on the
>> >> new arm arches which don't support this assembly inst= ruction any more. If
>> >> use ldrex/strex to replace swpb, the old arm arches don&#= 39;t support them. So
>> >> to avoid this issue, just disable the ARM assembler mutex= code, and use the
>> >> default pthreads mutex.
>> >>
>> >> Signed-off-by: Li Zhou <li.zhou@windriver.com>
>> >> Signed-off-by: Catalin Enache <catalin.enache@windriver.com= >
>> >> Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com>= ;
>> >> ---
>> >>=C2=A0 meta/recipes-support/db/db_5.3.28.bb | 13 +----------= --
>> >>=C2=A0 1 file changed, 1 insertion(+), 12 deletions(-)
>> >>
>> >> diff --git a/meta/recipes-support/db/db_5.3.28.bb
>> >> b/meta/recipes-support/db/db_5.3.28.bb
>> >> index 093ee44909..15b4155a29 100644
>> >> --- a/meta/recipes-support/db/db_5.3.28.bb
>> >> +++ b/meta/recipes-support/db/db_5.3.28.bb
>> >> @@ -59,18 +59,7 @@ FILES_SOLIBSDEV =3D "${libdir}/li= bdb.so
>> >> ${libdir}/libdb_cxx.so"
>> >>=C2=A0 # All the --disable-* options replace --enable-smal= lbuild, which breaks a
>> >> bunch of stuff (eg. postfix)=C2=A0 DB5_CONFIG ?=3D "= --enable-o_direct
>> >> --disable-cryptography --disable-queue --disable-replicat= ion
>> >> --disable-verify --disable-compat185 --disable-sql"<= br> >> >>
>> >> -EXTRA_OECONF =3D "${DB5_CONFIG} --enable-shared --e= nable-cxx --with-sysroot"
>> >> -
>> >> -# Override the MUTEX setting here, the POSIX library is = -# the default -
>> >> "POSIX/pthreads/library".
>> >> -# Don't ignore the nice SWP instruction on the ARM:<= br> >> >> -# These enable the ARM assembler mutex code, this won= 9;t -# work with thumb
>> >> compilation...
>> >> -ARM_MUTEX =3D "--with-mutex=3DARM/gcc-assembly"= ;
>> >> -MUTEX =3D ""
>> >> -MUTEX_arm =3D "${ARM_MUTEX}"
>> >> -MUTEX_armeb =3D "${ARM_MUTEX}"
>> >> -EXTRA_OECONF +=3D "${MUTEX} STRIP=3Dtrue"
>> >> +EXTRA_OECONF =3D "${DB5_CONFIG} --enable-shared --e= nable-cxx --with-sysroot
>> >> STRIP=3Dtrue"
>> >>=C2=A0 EXTRA_OEMAKE +=3D "LIBTOOL=3D'./${HOST_SYS= }-libtool'"
>> >>
>> >>=C2=A0 EXTRA_AUTORECONF +=3D "--exclude=3Dautoheader= =C2=A0 -I ${S}/dist/aclocal
>> >> -I${S}/dist/aclocal_java"
>> >> --
>> >> 2.17.1
>> >>
>> >> --
>> >> _______________________________________________
>> >> Openembedded-core mailing list
>> >> Openembedded-core@lists.openembedded.org
>> >> http://lists.opene= mbedded.org/mailman/listinfo/openembedded-core
>> >>
>> >
>> >
>> >
>> > --
>> > _______________________________________________
>> > Openembedded-core mailing list
>> > Openembedded-core@lists.openembedded.org
>> > http://lists.openembed= ded.org/mailman/listinfo/openembedded-core
>> >
--00000000000054063d056ea1113f--