<div><br></div><div><br><div class="gmail_quote"><div dir="auto">On Thu, Jun 14, 2018 at 1:01 PM Andre McCurdy <<a href="mailto:armccurdy@gmail.com">armccurdy@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, Jun 14, 2018 at 12:24 PM, Khem Raj <<a href="mailto:raj.khem@gmail.com" target="_blank">raj.khem@gmail.com</a>> wrote:<br>
> On Thu, Jun 14, 2018 at 12:12 PM Andre McCurdy <<a href="mailto:armccurdy@gmail.com" target="_blank">armccurdy@gmail.com</a>> wrote:<br>
>><br>
>> On Thu, Jun 14, 2018 at 9:40 AM, Khem Raj <<a href="mailto:raj.khem@gmail.com" target="_blank">raj.khem@gmail.com</a>> wrote:<br>
>> > On 6/14/18 5:10 AM, Herve Jourdain wrote:<br>
>> >> Hi,<br>
>> >><br>
>> >> I believe I solved that same problem by just adding, in the case of armv8<br>
>> >> (which I believe may be the new architecture you're referring to):<br>
>> >> MUTEX_armv8 = ""<br>
>> >> This way, it allows previous versions to work just like they did before,<br>
>> >> without having to disable ARM assembler mutex code for architectures that<br>
>> >> support it correctly - up to armv7ve I believe.<br>
>> >> Of course, we might need to also have a good definition for armv8, which is<br>
>> >> the object of another thread.<br>
>> ><br>
>> > right thats a better approach.<br>
>><br>
>> SWP is not guaranteed to work on SMP systems... and even if it does,<br>
>> performance is likely to be worse than the pthreads version (which can<br>
>> take advantage of the newer instructions).<br>
>><br>
>> <a href="https://community.arm.com/processors/b/blog/posts/locks-swps-and-two-smoking-barriers" rel="noreferrer" target="_blank">https://community.arm.com/processors/b/blog/posts/locks-swps-and-two-smoking-barriers</a><br>
>><br>
>> In general, use of hand optimised assembler mutex implementations in<br>
>> user space isn't something to be encouraged - use pthreads (or maybe a<br>
>> gcc intrinsic) instead.<br>
>><br>
><br>
> question is about disabling it on old arm machines, do we have data where<br>
> we know that other sync methods without swp works better on armv5 and lower ?<br>
<br>
On armv5 and below a hand optimised implementation using SWP is likely<br>
to be faster than pthreads. No one is suggesting otherwise.<br>
<br>
On SMP (highly likely nowadays for armv7 and above), SWP simply might<br>
not work (aside from the fact that if it does work, it's likely to be<br>
slower than pthreads). It's not really a question of performance<br>
there, so the proposal to only disable SWP for armv8 doesn't seem like<br>
a safe solution.<br>
</blockquote><div dir="auto"><br></div><div dir="auto">Suggestion is not to just do it for armv8 but</div><div dir="auto">To keep it there where its beneficial </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Using pthreads unconditionally is safe and easy. Unless you can prove<br>
that hand optimised SWP is really a big win for armv5 (is anyone<br>
really running a performance critical database on an armv5 system?)<br>
why not keep the recipe simple and use pthreads everywhere?<br>
<br>
>> I think the original patch is good.<br>
>><br>
>> >> Cheers,<br>
>> >> Herve<br>
>> >><br>
>> >> -----Original Message-----<br>
>> >> From: <a href="mailto:openembedded-core-bounces@lists.openembedded.org" target="_blank">openembedded-core-bounces@lists.openembedded.org</a><br>
>> >> [mailto:<a href="mailto:openembedded-core-bounces@lists.openembedded.org" target="_blank">openembedded-core-bounces@lists.openembedded.org</a>] On Behalf Of<br>
>> >> Ovidiu Panait<br>
>> >> Sent: jeudi 14 juin 2018 13:55<br>
>> >> To: <a href="mailto:openembedded-core@lists.openembedded.org" target="_blank">openembedded-core@lists.openembedded.org</a><br>
>> >> Subject: [OE-core] [PATCH 1/1] db: disable the ARM assembler mutex code<br>
>> >><br>
>> >> The swpb in macro MUTEX_SET will cause "undefined instruction" error on the<br>
>> >> new arm arches which don't support this assembly instruction any more. If<br>
>> >> use ldrex/strex to replace swpb, the old arm arches don't support them. So<br>
>> >> to avoid this issue, just disable the ARM assembler mutex code, and use the<br>
>> >> default pthreads mutex.<br>
>> >><br>
>> >> Signed-off-by: Li Zhou <<a href="mailto:li.zhou@windriver.com" target="_blank">li.zhou@windriver.com</a>><br>
>> >> Signed-off-by: Catalin Enache <<a href="mailto:catalin.enache@windriver.com" target="_blank">catalin.enache@windriver.com</a>><br>
>> >> Signed-off-by: Ovidiu Panait <<a href="mailto:ovidiu.panait@windriver.com" target="_blank">ovidiu.panait@windriver.com</a>><br>
>> >> ---<br>
>> >> meta/recipes-support/db/<a href="http://db_5.3.28.bb" rel="noreferrer" target="_blank">db_5.3.28.bb</a> | 13 +------------<br>
>> >> 1 file changed, 1 insertion(+), 12 deletions(-)<br>
>> >><br>
>> >> diff --git a/meta/recipes-support/db/<a href="http://db_5.3.28.bb" rel="noreferrer" target="_blank">db_5.3.28.bb</a><br>
>> >> b/meta/recipes-support/db/<a href="http://db_5.3.28.bb" rel="noreferrer" target="_blank">db_5.3.28.bb</a><br>
>> >> index 093ee44909..15b4155a29 100644<br>
>> >> --- a/meta/recipes-support/db/<a href="http://db_5.3.28.bb" rel="noreferrer" target="_blank">db_5.3.28.bb</a><br>
>> >> +++ b/meta/recipes-support/db/<a href="http://db_5.3.28.bb" rel="noreferrer" target="_blank">db_5.3.28.bb</a><br>
>> >> @@ -59,18 +59,7 @@ FILES_SOLIBSDEV = "${libdir}/libdb.so<br>
>> >> ${libdir}/libdb_cxx.so"<br>
>> >> # All the --disable-* options replace --enable-smallbuild, which breaks a<br>
>> >> bunch of stuff (eg. postfix) DB5_CONFIG ?= "--enable-o_direct<br>
>> >> --disable-cryptography --disable-queue --disable-replication<br>
>> >> --disable-verify --disable-compat185 --disable-sql"<br>
>> >><br>
>> >> -EXTRA_OECONF = "${DB5_CONFIG} --enable-shared --enable-cxx --with-sysroot"<br>
>> >> -<br>
>> >> -# Override the MUTEX setting here, the POSIX library is -# the default -<br>
>> >> "POSIX/pthreads/library".<br>
>> >> -# Don't ignore the nice SWP instruction on the ARM:<br>
>> >> -# These enable the ARM assembler mutex code, this won't -# work with thumb<br>
>> >> compilation...<br>
>> >> -ARM_MUTEX = "--with-mutex=ARM/gcc-assembly"<br>
>> >> -MUTEX = ""<br>
>> >> -MUTEX_arm = "${ARM_MUTEX}"<br>
>> >> -MUTEX_armeb = "${ARM_MUTEX}"<br>
>> >> -EXTRA_OECONF += "${MUTEX} STRIP=true"<br>
>> >> +EXTRA_OECONF = "${DB5_CONFIG} --enable-shared --enable-cxx --with-sysroot<br>
>> >> STRIP=true"<br>
>> >> EXTRA_OEMAKE += "LIBTOOL='./${HOST_SYS}-libtool'"<br>
>> >><br>
>> >> EXTRA_AUTORECONF += "--exclude=autoheader -I ${S}/dist/aclocal<br>
>> >> -I${S}/dist/aclocal_java"<br>
>> >> --<br>
>> >> 2.17.1<br>
>> >><br>
>> >> --<br>
>> >> _______________________________________________<br>
>> >> Openembedded-core mailing list<br>
>> >> <a href="mailto:Openembedded-core@lists.openembedded.org" target="_blank">Openembedded-core@lists.openembedded.org</a><br>
>> >> <a href="http://lists.openembedded.org/mailman/listinfo/openembedded-core" rel="noreferrer" target="_blank">http://lists.openembedded.org/mailman/listinfo/openembedded-core</a><br>
>> >><br>
>> ><br>
>> ><br>
>> ><br>
>> > --<br>
>> > _______________________________________________<br>
>> > Openembedded-core mailing list<br>
>> > <a href="mailto:Openembedded-core@lists.openembedded.org" target="_blank">Openembedded-core@lists.openembedded.org</a><br>
>> > <a href="http://lists.openembedded.org/mailman/listinfo/openembedded-core" rel="noreferrer" target="_blank">http://lists.openembedded.org/mailman/listinfo/openembedded-core</a><br>
>> ><br>
</blockquote></div></div>