All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Johannes Weiner <hannes@saeurebad.de>
Cc: Nick Piggin <nickpiggin@yahoo.com.au>,
	LKML <linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@elte.hu>,
	Jens Axboe <axboe@kernel.dk>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Christoph Lameter <clameter@linux-foundation.org>,
	Petr Tesarik <ptesarik@suse.cz>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Xen devel <xen-devel@lists.xensource.com>,
	Thomas Friebel <thomas.friebel@amd.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Subject: Re: [PATCH RFC 4/4] xen: implement Xen-specific spinlocks
Date: Tue, 08 Jul 2008 00:15:21 -0700	[thread overview]
Message-ID: <48731409.9070304@goop.org> (raw)
In-Reply-To: <87tzf0q3te.fsf@saeurebad.de>

Johannes Weiner wrote:
>> +static DEFINE_PER_CPU(int, lock_kicker_irq) = -1;
>> +static DEFINE_PER_CPU(struct xen_spinlock *, lock_spinners);
>>     
>
> The plural is a bit misleading, as this is a single pointer per CPU.
>   

Yeah.  And it's wrong because it's specifically *not* spinning, but 
blocking.

>> +static noinline void xen_spin_unlock_slow(struct xen_spinlock *xl)
>> +{
>> +	int cpu;
>> +
>> +	for_each_online_cpu(cpu) {
>>     
>
> Would it be feasible to have a bitmap for the spinning CPUs in order to
> do a for_each_spinning_cpu() here instead?  Or is setting a bit in
> spinning_lock() and unsetting it in unspinning_lock() more overhead than
> going over all CPUs here?
>   

Not worthwhile, I think.  This is a very rare path: it will only happen 
if 1) there's lock contention, that 2) wasn't resolved within the 
timeout.  In practice, this gets called a few thousand times per cpu 
over a kernbench, which is nothing.

My very original version of this code kept a bitmask of interested CPUs 
within the lock, but there's only space for 24 cpus if we still use a 
byte for the lock itself.  It all turned out fairly awkward, and this 
version is a marked improvement.

    J

WARNING: multiple messages have this Message-ID (diff)
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Johannes Weiner <hannes@saeurebad.de>
Cc: Jens Axboe <axboe@kernel.dk>,
	Nick Piggin <nickpiggin@yahoo.com.au>,
	Xen devel <xen-devel@lists.xensource.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Christoph Lameter <clameter@linux-foundation.org>,
	Petr Tesarik <ptesarik@suse.cz>,
	LKML <linux-kernel@vger.kernel.org>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Thomas Friebel <thomas.friebel@amd.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Ingo Molnar <mingo@elte.hu>
Subject: Re: [PATCH RFC 4/4] xen: implement Xen-specific spinlocks
Date: Tue, 08 Jul 2008 00:15:21 -0700	[thread overview]
Message-ID: <48731409.9070304@goop.org> (raw)
In-Reply-To: <87tzf0q3te.fsf@saeurebad.de>

Johannes Weiner wrote:
>> +static DEFINE_PER_CPU(int, lock_kicker_irq) = -1;
>> +static DEFINE_PER_CPU(struct xen_spinlock *, lock_spinners);
>>     
>
> The plural is a bit misleading, as this is a single pointer per CPU.
>   

Yeah.  And it's wrong because it's specifically *not* spinning, but 
blocking.

>> +static noinline void xen_spin_unlock_slow(struct xen_spinlock *xl)
>> +{
>> +	int cpu;
>> +
>> +	for_each_online_cpu(cpu) {
>>     
>
> Would it be feasible to have a bitmap for the spinning CPUs in order to
> do a for_each_spinning_cpu() here instead?  Or is setting a bit in
> spinning_lock() and unsetting it in unspinning_lock() more overhead than
> going over all CPUs here?
>   

Not worthwhile, I think.  This is a very rare path: it will only happen 
if 1) there's lock contention, that 2) wasn't resolved within the 
timeout.  In practice, this gets called a few thousand times per cpu 
over a kernbench, which is nothing.

My very original version of this code kept a bitmask of interested CPUs 
within the lock, but there's only space for 24 cpus if we still use a 
byte for the lock itself.  It all turned out fairly awkward, and this 
version is a marked improvement.

    J

  parent reply	other threads:[~2008-07-08  7:15 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-07 19:07 [PATCH RFC 0/4] Paravirtual spinlocks Jeremy Fitzhardinge
2008-07-07 19:07 ` Jeremy Fitzhardinge
2008-07-07 19:07 ` [PATCH RFC 1/4] x86/paravirt: add hooks for spinlock operations Jeremy Fitzhardinge
2008-07-07 19:07   ` Jeremy Fitzhardinge
2008-07-07 19:07 ` Jeremy Fitzhardinge
2008-07-07 19:07 ` [PATCH RFC 2/4] paravirt: introduce a "lock-byte" spinlock implementation Jeremy Fitzhardinge
2008-07-07 19:07   ` Jeremy Fitzhardinge
2008-07-07 19:07 ` Jeremy Fitzhardinge
2008-07-07 19:07 ` [PATCH RFC 3/4] xen: use lock-byte " Jeremy Fitzhardinge
2008-07-07 19:07   ` Jeremy Fitzhardinge
2008-07-07 19:07 ` Jeremy Fitzhardinge
2008-07-07 19:07 ` [PATCH RFC 4/4] xen: implement Xen-specific spinlocks Jeremy Fitzhardinge
2008-07-07 19:07   ` Jeremy Fitzhardinge
2008-07-08  6:37   ` Johannes Weiner
2008-07-08  7:15     ` Jeremy Fitzhardinge
2008-07-08  7:15     ` Jeremy Fitzhardinge [this message]
2008-07-08  7:15       ` Jeremy Fitzhardinge
2008-07-08  7:30       ` Johannes Weiner
2008-07-08  7:30       ` Johannes Weiner
2008-07-08  6:37   ` Johannes Weiner
2008-07-08  0:29 ` [PATCH RFC 0/4] Paravirtual spinlocks Rusty Russell
2008-07-08  0:29 ` Rusty Russell
2008-07-08  0:37   ` Jeremy Fitzhardinge
2008-07-08  0:37     ` Jeremy Fitzhardinge
2008-07-08  1:01     ` Rusty Russell
2008-07-08  1:01     ` Rusty Russell
2008-07-08  0:37   ` Jeremy Fitzhardinge
2008-07-08  4:51   ` Nick Piggin
2008-07-08  4:51     ` Nick Piggin
2008-07-08  5:28     ` Jeremy Fitzhardinge
2008-07-08  5:28       ` Jeremy Fitzhardinge
2008-07-08  5:28     ` Jeremy Fitzhardinge
2008-07-08  4:51   ` Nick Piggin
2008-07-09 12:28 ` Ingo Molnar
2008-07-09 12:28 ` Ingo Molnar
2008-07-09 12:28   ` Ingo Molnar
2008-07-09 12:35   ` [patch] x86: paravirt spinlocks, !CONFIG_SMP build fixes (was: Re: [PATCH RFC 0/4] Paravirtual spinlocks) Ingo Molnar
2008-07-09 12:35     ` Ingo Molnar
2008-07-09 12:35   ` Ingo Molnar
2008-07-09 12:39   ` [patch] x86: paravirt spinlocks, modular build fix " Ingo Molnar
2008-07-09 12:39     ` Ingo Molnar
2008-07-09 12:39   ` Ingo Molnar
2008-07-09 13:33   ` [PATCH RFC 0/4] Paravirtual spinlocks Ingo Molnar
2008-07-09 13:33     ` Ingo Molnar
2008-07-09 13:49     ` [patch] x86, paravirt-spinlocks: fix boot hang (was: Re: [PATCH RFC 0/4] Paravirtual spinlocks) Ingo Molnar
2008-07-09 13:49       ` Ingo Molnar
2008-07-09 15:55       ` [patch] x86, paravirt-spinlocks: fix boot hang Jeremy Fitzhardinge
2008-07-09 19:26         ` Ingo Molnar
2008-07-09 19:26           ` Ingo Molnar
2008-07-09 19:26         ` Ingo Molnar
2008-07-09 15:55       ` Jeremy Fitzhardinge
2008-07-09 13:49     ` [patch] x86, paravirt-spinlocks: fix boot hang (was: Re: [PATCH RFC 0/4] Paravirtual spinlocks) Ingo Molnar
2008-07-09 13:33   ` [PATCH RFC 0/4] Paravirtual spinlocks Ingo Molnar

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=48731409.9070304@goop.org \
    --to=jeremy@goop.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=axboe@kernel.dk \
    --cc=clameter@linux-foundation.org \
    --cc=hannes@saeurebad.de \
    --cc=jeremy.fitzhardinge@citrix.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=nickpiggin@yahoo.com.au \
    --cc=ptesarik@suse.cz \
    --cc=thomas.friebel@amd.com \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=xen-devel@lists.xensource.com \
    /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.