Linux MIPS Architecture development
 help / color / mirror / Atom feed
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
        }
-----

  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