From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: LKML <linux-kernel@vger.kernel.org>,
x86@kernel.org, Andi Kleen <andi@firstfloor.org>,
Nick Piggin <nickpiggin@yahoo.com.au>,
Jens Axboe <jens.axboe@oracle.com>
Subject: Re: [PATCH 0 of 9] x86/smp function calls: convert x86 tlb flushes to use function calls [POST 2]
Date: Mon, 18 Aug 2008 23:18:13 -0700 [thread overview]
Message-ID: <48AA65A5.8020408@goop.org> (raw)
In-Reply-To: <20080819012816.GA7897@elte.hu>
Ingo Molnar wrote:
> * Ingo Molnar <mingo@elte.hu> wrote:
>
>
>> nice stuff!
>>
>> I suspect the extra cost might be worth it for two reasons: 1) we
>> could optimize the cross-call implementation further 2) on systems
>> where TLB flushes actually matter, the ability to overlap multiple TLB
>> flushes to the same single CPU might improve workloads.
>>
>> FYI, i've created a new -tip topic for your patches, tip/x86/tlbflush.
>> It's based on tip/irq/sparseirq (there are a good deal of dependencies
>> with that topic).
>>
>
> i threw it into -tip testing for a while - triggered the lockdep warning
> on 64-bit below.
>
> Ingo
>
> ------------>
> checking TSC synchronization [CPU#0 -> CPU#1]: passed.
>
> =============================================
> [ INFO: possible recursive locking detected ]
> 2.6.27-rc3-tip #1
> ---------------------------------------------
> swapper/0 is trying to acquire lock:
> (&call_function_queues[i].lock){....}, at: [<ffffffff8026cbba>] ipi_call_lock_irq+0x25/0x2e
>
> but task is already holding lock:
> (&call_function_queues[i].lock){....}, at: [<ffffffff8026cbba>] ipi_call_lock_irq+0x25/0x2e
>
I think this might be a spurious "holding multiple locks in the same
class" bug. All the queue locks are presumably in the same class, and
ipi_call_lock_irq() wants to hold them all to lock out any IPIs.
Spurious because this is the only place which holds more than one queue
lock, and it always locks 0->N.
I guess the fix is to use an outer lock and use spin_lock_nested() (now
that it exists). Something along these lines?
J
diff -r 22ebc3296a6f kernel/smp.c
--- a/kernel/smp.c Mon Aug 18 15:12:14 2008 -0700
+++ b/kernel/smp.c Mon Aug 18 22:52:22 2008 -0700
@@ -18,6 +18,9 @@
#else
#define NQUEUES 1
#endif
+
+/* Hold queues_lock when taking more than one queue[].lock at once */
+static DEFINE_SPINLOCK(queues_lock);
static DEFINE_PER_CPU(struct call_single_queue, call_single_queue);
struct ____cacheline_aligned queue {
@@ -446,8 +449,10 @@
{
int i;
+ spin_lock_irq(&queues_lock);
+
for(i = 0; i < NQUEUES; i++)
- spin_lock_irq(&call_function_queues[i].lock);
+ spin_lock_nest_lock(&call_function_queues[i].lock, &queues_lock);
}
void ipi_call_unlock_irq(void)
@@ -455,7 +460,9 @@
int i;
for(i = 0; i < NQUEUES; i++)
- spin_unlock_irq(&call_function_queues[i].lock);
+ spin_unlock(&call_function_queues[i].lock);
+
+ spin_unlock_irq(&queues_lock);
}
next prev parent reply other threads:[~2008-08-19 6:18 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-18 18:23 [PATCH 0 of 9] x86/smp function calls: convert x86 tlb flushes to use function calls [POST 2] Jeremy Fitzhardinge
2008-08-18 18:23 ` [PATCH 1 of 9] x86: put tlb_flush_others() stats in debugfs Jeremy Fitzhardinge
2008-08-18 18:23 ` [PATCH 2 of 9] x86-32: use smp_call_function_mask for SMP TLB invalidations Jeremy Fitzhardinge
2008-08-18 18:23 ` [PATCH 3 of 9] x86-64: " Jeremy Fitzhardinge
2008-08-18 18:23 ` [PATCH 4 of 9] x86: make tlb_32|64 closer Jeremy Fitzhardinge
2008-08-18 18:23 ` [PATCH 5 of 9] x86: unify tlb.c Jeremy Fitzhardinge
2008-08-18 18:23 ` [PATCH 6 of 9] smp_function_call: add multiple queues for scalability Jeremy Fitzhardinge
2008-08-18 18:23 ` [PATCH 7 of 9] x86: add multiple smp_call_function queues Jeremy Fitzhardinge
2008-08-18 18:23 ` [PATCH 8 of 9] x86: make number of smp_call_function queues truely configurable Jeremy Fitzhardinge
2008-08-18 18:23 ` [PATCH 9 of 9] smp function calls: add kernel parameter to disable multiple queues Jeremy Fitzhardinge
2008-08-19 0:45 ` [PATCH 0 of 9] x86/smp function calls: convert x86 tlb flushes to use function calls [POST 2] Ingo Molnar
2008-08-19 1:28 ` Ingo Molnar
2008-08-19 6:18 ` Jeremy Fitzhardinge [this message]
2008-08-19 9:27 ` Ingo Molnar
2008-08-19 14:58 ` Jeremy Fitzhardinge
2008-08-19 9:45 ` Peter Zijlstra
2008-08-19 14:58 ` Jeremy Fitzhardinge
2008-08-19 5:37 ` Jeremy Fitzhardinge
2008-08-19 9:31 ` Ingo Molnar
2008-08-19 9:56 ` Nick Piggin
2008-08-19 10:20 ` Ingo Molnar
2008-08-19 11:08 ` Nick Piggin
2008-08-19 11:44 ` Ingo Molnar
2008-08-19 10:24 ` Ingo Molnar
2008-08-19 10:49 ` Nick Piggin
2008-08-19 10:31 ` Andi Kleen
2008-08-19 11:04 ` Nick Piggin
2008-08-19 11:20 ` Andi Kleen
2008-08-19 7:32 ` Andi Kleen
2008-08-19 7:44 ` Jeremy Fitzhardinge
2008-08-19 7:48 ` Andi Kleen
2008-08-19 8:04 ` Jeremy Fitzhardinge
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=48AA65A5.8020408@goop.org \
--to=jeremy@goop.org \
--cc=andi@firstfloor.org \
--cc=jens.axboe@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=nickpiggin@yahoo.com.au \
--cc=x86@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.