From: Ralf Baechle <ralf@linux-mips.org>
To: Kumba <kumba@gentoo.org>
Cc: libc-ports@sources.redhat.com, Daniel Jacobowitz <drow@false.org>,
Linux MIPS List <linux-mips@linux-mips.org>
Subject: Re: [PATCH]: R10000 Needs LL/SC Workaround in Glibc
Date: Sat, 1 Nov 2008 11:26:43 +0000 [thread overview]
Message-ID: <20081101112643.GA2249@linux-mips.org> (raw)
In-Reply-To: <490A912A.8030901@gentoo.org>
On Fri, Oct 31, 2008 at 01:01:30AM -0400, Kumba wrote:
> +#ifndef (_MIPS_ARCH_R10000)
> +#define R10K_BEQZ_INSN "beqz %1,1b\n"
> +#else
> +#define R10K_BEQZ_INSN "beqzl %1,1b\n"
> +#endif
In the kernel we have very good knowledge about what types of processors
are being used for what configuration; much less in userland and the code
as suggested by you would result in a silent failure on affected R10000
machines if version built not for the R10000 was being used - iow no
improvment over what we have right now. So for userland I'd prefer to
o MIPS I builds: use the some 28 nops.
o Builds for MIPS II or better: always use the branch likely
o A runtime test would have to be implemented pessimisticall because it
would have to rely on /proc being mounted which isn't available early in
the boot process. It's probably going to add more overhead than it
saves anyway.
There is a price for using branch likely - but not that high. In the grand
picture it'll almost certainly vanish in the benchmarking noise.
Ralf
next prev parent reply other threads:[~2008-11-01 11:27 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-31 5:01 [PATCH]: R10000 Needs LL/SC Workaround in Glibc Kumba
2008-11-01 7:33 ` Kumba
2008-11-01 11:26 ` Ralf Baechle [this message]
2008-11-04 7:16 ` Kumba
2008-11-01 17:23 ` James Perkins
2008-11-04 7:16 ` Kumba
2008-11-23 4:16 ` Kumba
2009-01-27 15:29 ` Daniel Jacobowitz
2009-01-27 16:13 ` Maciej W. Rozycki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20081101112643.GA2249@linux-mips.org \
--to=ralf@linux-mips.org \
--cc=drow@false.org \
--cc=kumba@gentoo.org \
--cc=libc-ports@sources.redhat.com \
--cc=linux-mips@linux-mips.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.