From: Ed Martini <martini@c2micro.com>
To: linux-mips@linux-mips.org
Subject: Observations on LLSC and SMP
Date: Fri, 25 Mar 2005 11:24:05 -0800 [thread overview]
Message-ID: <42446555.6090005@c2micro.com> (raw)
In-Reply-To: <20050316120647.GB8563@linux-mips.org>
In include/asm-mips/ atomic.h, bitops.h and system.h there are a bunch
of inline functions which contain this logic:
if (cpu_has_llsc && R10000_LLSC_WAR) {
__asm__ (stuff)
} else if (cpu_has_llsc) {
__asm__ (other stuff)
} else {
C lang stuff;
}
My two observations relate to both code size and runtime performance.
These observations don't affect my situation, so I'm not inclined to
spend a bunch of time on it, but maybe someone else is interested. This
should be especially interesting since these inline functions are used
all over the kernel, so it might actually make a marginally significant
difference.
I suppose there's a reason this code is the way it is. If so, feel free
to ignore me or flame away.
1. If the first part of the if were an ifdef instead it would result in
a code size reduction as well as a runtime performance gain.
2. In atomic.h the "C lang stuff" is wrapped with a spinlock. In the
SMP case the spinlock will result in code that contains ll and sc
instructions, so I infer that there are no SMP system configs that use
CPUs that don't have the ll and sc instructions.
Paranoid version:
-----
if (cpu_has_llsc) {
#ifdef R10000_LLSC_WAR
__asm__ (stuff)
#else
__asm__ (other stuff)
#endif
} else {
#ifdef CONFIG_SMP
panic("SMP on CPUs with no LLSC is broken\n");
#else
C lang stuff;
#endif
}
-----
Most efficient version:
-----
#ifndef CONFIG_SMP
if (cpu_has_llsc)
#endif
{
#ifdef R10000_LLSC_WAR
__asm__ (stuff)
#else
__asm__ (other stuff)
#endif
}
-----
next prev parent reply other threads:[~2005-03-25 19:26 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-10 23:42 initrd problem Ed Martini
2005-03-11 0:41 ` Kumba
2005-03-14 11:01 ` Ralf Baechle
2005-03-15 22:37 ` Ed Martini
2005-03-16 12:06 ` Ralf Baechle
2005-03-17 0:23 ` initrd/initramfs problem Ed Martini
2005-03-25 19:24 ` Ed Martini [this message]
2005-03-25 19:37 ` Observations on LLSC and SMP Daniel Jacobowitz
2005-03-25 22:46 ` Ed Martini
2005-03-25 22:53 ` Daniel Jacobowitz
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=42446555.6090005@c2micro.com \
--to=martini@c2micro.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox