From: Daniel Hellstrom <daniel@gaisler.com>
To: sparclinux@vger.kernel.org
Subject: SPARC32 SMP IRQ15 question
Date: Thu, 16 Dec 2010 14:24:02 +0000 [thread overview]
Message-ID: <4D0A2102.8030100@gaisler.com> (raw)
Hello Dave,
I have an architectural question about the SPARC32 port regarding how
IRQ15 is used for cross calls.
Why is IRQ15, the non-maskable IRQ, used for cross calls? Would it not
be safer to use IRQ14?
Since IRQ15 is non-maskable it will even interrupt spin_lock_irqsave()
protected reqions. I assume it is safe as long as the cross call
function run in IRQ context does not try to take the same spinlock, for
that would create a dead lock I believe. For example atomic_add() on
SPARC32 below is implemented using one of four global spinlocks, does
that mean that we can not use atomic functions at all from within a
cross call function?
#define atomic_add(i, v) ((void)__atomic_add_return( (int)(i), (v)))
#define ATOMIC_HASH_SIZE 4
#define ATOMIC_HASH(a) (&__atomic_hash[(((unsigned long)a)>>8) &
(ATOMIC_HASH_SIZE-1)])
spinlock_t __atomic_hash[ATOMIC_HASH_SIZE] = {
[0 ... (ATOMIC_HASH_SIZE-1)] = SPIN_LOCK_UNLOCKED
};
int __atomic_add_return(int i, atomic_t *v)
{
int ret;
unsigned long flags;
spin_lock_irqsave(ATOMIC_HASH(v), flags);
ret = (v->counter += i);
spin_unlock_irqrestore(ATOMIC_HASH(v), flags);
return ret;
}
This particular case is interesting since atomic instructions are used
by drain_local_pages() helper functions, which is scheduled as a cross
call in drain_all_pages():
#0 0xf02cb884 0xf14b97a0 _raw_spin_lock_irqsave + 0x54
#1 0xf0195024 0xf14b9800 __atomic_add_return + 0x18 (via
zone_page_state_add() include/linux/vmstat.h: 145)
#2 0xf007dfa8 0xf14b9860 __mod_zone_page_state + 0x64
(mm/vmstat.c: 165)
#3 0xf006f9cc 0xf14b98c0 free_pcppages_bulk + 0x340
(mm/page_alloc.c: 586)
#4 0xf006fb58 0xf14b9938 drain_local_pages + 0x64
#5 0xf001cb00 0xf14b9998 leon_cross_call_irq + 0x3c
/*
* Spill all the per-cpu pages from all CPUs back into the buddy allocator
*/
void drain_all_pages(void)
{
on_each_cpu(drain_local_pages, NULL, 1);
}
Best Regards,
Daniel Hellstrom
Aeroflex Gaisler
next reply other threads:[~2010-12-16 14:24 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-16 14:24 Daniel Hellstrom [this message]
2010-12-21 21:02 ` SPARC32 SMP IRQ15 question David Miller
2010-12-21 22:44 ` Jiri Gaisler
2010-12-22 3:54 ` David Miller
2010-12-22 9:19 ` Alex Buell
2010-12-22 9:51 ` Jiri Gaisler
2010-12-22 12:27 ` Daniel Hellstrom
2010-12-22 19:53 ` David Miller
2010-12-22 19:56 ` David Miller
2010-12-22 20:23 ` Alex Buell
2010-12-22 22:28 ` David Miller
2010-12-26 12:34 ` Kjetil Oftedal
2010-12-26 14:44 ` Jiri Gaisler
2010-12-27 1:55 ` David Miller
2010-12-27 17:28 ` crn
2011-01-03 14:14 ` Daniel Hellstrom
2011-01-03 14:19 ` Daniel Hellstrom
2011-01-26 17:02 ` Daniel Hellstrom
2011-01-26 19:52 ` David Miller
2011-01-26 21:28 ` daniel
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=4D0A2102.8030100@gaisler.com \
--to=daniel@gaisler.com \
--cc=sparclinux@vger.kernel.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.