All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Nick Piggin <npiggin@suse.de>, Jan Beulich <JBeulich@novell.com>,
	Avi Kivity <avi@redhat.com>,
	Xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [PATCH RFC 10/12] x86/pvticketlock: keep count of blocked cpus
Date: Tue, 03 Aug 2010 08:45:26 -0700	[thread overview]
Message-ID: <4C583996.1090805@goop.org> (raw)
In-Reply-To: <1280824360.1923.421.camel@laptop>

  On 08/03/2010 01:32 AM, Peter Zijlstra wrote:
> On Fri, 2010-07-16 at 18:03 -0700, Jeremy Fitzhardinge wrote:
>> @@ -26,6 +26,9 @@ typedef struct arch_spinlock {
>>                          __ticket_t head, tail;
>>                  } tickets;
>>          };
>> +#ifdef CONFIG_PARAVIRT_SPINLOCKS
>> +       __ticket_t waiting;
>> +#endif
>>   } arch_spinlock_t;
> This bloats spinlock_t from u32 to u64 on most distro configs I think,
> since they'll have NR_CPUS=4096 or something large like that and
> probably also want to have this PARAVIRT_SPINLOCKS thing.

Yes, it is very unfortunate.  In principle I could make it work with a 
single bit: set it when a cpu blocks and will need kicking; clear it 
when the lock becomes uncontended again (since everything is FIFO, so if 
something blocks itself there's a good chance that everything afterwards 
will also decide to block).  But a bit takes as much space as a word 
(and it isn't obvious to me how to implement the "clearing when it 
becomes uncontended" part in a race-free way). (But see below for some 
handwaving)

I could store this out in a secondary structure, but it really needs to 
be efficient to access from the unlock fast-path (to determine whether 
it needs to do the slow-path kick), so something out of line isn't going 
to work.

Without the separate "waiting" counter, the previous code just checked 
to see if there was anyone else has a ticket on the lock.  This is too 
pessimistic, since it isn't all that uncommon to have someone else who 
has been waiting on the lock for a little while, but has not yet decided 
to block themselves, and it results in many spurious calls into the 
unlock slow path.

I was thinking of getting a bit in the ticket lock structure by stealing 
a counter bit: halve the supported number of cpus (128 for byte, 32k for 
word), add/sub 2, and use the LSB for the "needs kicking" flag.  And 
that actually gives us two bits to play with, which may be useful for 
dealing with the clearing race (perhaps can be done cleverly in the 
unlock itself, or something).  But I haven't thought this through in detail.

     J

WARNING: multiple messages have this Message-ID (diff)
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Nick Piggin <npiggin@suse.de>,
	Xen-devel <xen-devel@lists.xensource.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Jan Beulich <JBeulich@novell.com>, Avi Kivity <avi@redhat.com>
Subject: Re: [PATCH RFC 10/12] x86/pvticketlock: keep count of blocked cpus
Date: Tue, 03 Aug 2010 08:45:26 -0700	[thread overview]
Message-ID: <4C583996.1090805@goop.org> (raw)
In-Reply-To: <1280824360.1923.421.camel@laptop>

  On 08/03/2010 01:32 AM, Peter Zijlstra wrote:
> On Fri, 2010-07-16 at 18:03 -0700, Jeremy Fitzhardinge wrote:
>> @@ -26,6 +26,9 @@ typedef struct arch_spinlock {
>>                          __ticket_t head, tail;
>>                  } tickets;
>>          };
>> +#ifdef CONFIG_PARAVIRT_SPINLOCKS
>> +       __ticket_t waiting;
>> +#endif
>>   } arch_spinlock_t;
> This bloats spinlock_t from u32 to u64 on most distro configs I think,
> since they'll have NR_CPUS=4096 or something large like that and
> probably also want to have this PARAVIRT_SPINLOCKS thing.

Yes, it is very unfortunate.  In principle I could make it work with a 
single bit: set it when a cpu blocks and will need kicking; clear it 
when the lock becomes uncontended again (since everything is FIFO, so if 
something blocks itself there's a good chance that everything afterwards 
will also decide to block).  But a bit takes as much space as a word 
(and it isn't obvious to me how to implement the "clearing when it 
becomes uncontended" part in a race-free way). (But see below for some 
handwaving)

I could store this out in a secondary structure, but it really needs to 
be efficient to access from the unlock fast-path (to determine whether 
it needs to do the slow-path kick), so something out of line isn't going 
to work.

Without the separate "waiting" counter, the previous code just checked 
to see if there was anyone else has a ticket on the lock.  This is too 
pessimistic, since it isn't all that uncommon to have someone else who 
has been waiting on the lock for a little while, but has not yet decided 
to block themselves, and it results in many spurious calls into the 
unlock slow path.

I was thinking of getting a bit in the ticket lock structure by stealing 
a counter bit: halve the supported number of cpus (128 for byte, 32k for 
word), add/sub 2, and use the LSB for the "needs kicking" flag.  And 
that actually gives us two bits to play with, which may be useful for 
dealing with the clearing race (perhaps can be done cleverly in the 
unlock itself, or something).  But I haven't thought this through in detail.

     J

  parent reply	other threads:[~2010-08-03 15:45 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-17  1:03 [PATCH RFC 00/12] X86 ticket lock cleanups and improvements Jeremy Fitzhardinge
2010-07-17  1:03 ` [PATCH RFC 12/12] x86/pvticketlock: use callee-save for unlock_kick as well Jeremy Fitzhardinge
2010-07-17  1:03 ` [PATCH RFC 08/12] x86/ticketlock: collapse a layer of functions Jeremy Fitzhardinge
2010-07-17  1:03 ` [PATCH RFC 02/12] x86/ticketlock: convert spin loop to C Jeremy Fitzhardinge
2010-08-02 15:07   ` Peter Zijlstra
2010-08-02 15:17     ` Jeremy Fitzhardinge
2010-08-02 15:17       ` Jeremy Fitzhardinge
2010-08-06 12:43       ` Jan Beulich
2010-08-06 14:53         ` Jeremy Fitzhardinge
2010-08-06 20:17           ` H. Peter Anvin
2010-08-06 20:17             ` H. Peter Anvin
2010-08-06 20:33             ` Jeremy Fitzhardinge
2010-08-06 20:33               ` Jeremy Fitzhardinge
2010-08-06 21:09               ` H. Peter Anvin
2010-08-06 21:09                 ` H. Peter Anvin
2010-08-06 22:03                 ` Jeremy Fitzhardinge
2010-07-17  1:03 ` [PATCH RFC 06/12] x86/ticketlock: make __ticket_spin_trylock common Jeremy Fitzhardinge
2010-07-17  1:03 ` [PATCH RFC 04/12] x86/ticketlock: make large and small ticket versions of spin_lock the same Jeremy Fitzhardinge
2010-07-17  1:03 ` [PATCH RFC 11/12] x86/pvticketlock: use callee-save for lock_spinning Jeremy Fitzhardinge
2010-07-17  1:03 ` [PATCH RFC 01/12] x86/ticketlock: clean up types and accessors Jeremy Fitzhardinge
2010-07-17  1:03 ` [PATCH RFC 09/12] xen/pvticketlock: Xen implementation for PV ticket locks Jeremy Fitzhardinge
2010-09-26 11:39   ` Srivatsa Vaddagiri
2010-09-26 22:34     ` Jeremy Fitzhardinge
2010-09-26 22:34       ` Jeremy Fitzhardinge
2011-01-18 16:27       ` Srivatsa Vaddagiri
2011-01-19  1:28         ` Jeremy Fitzhardinge
2010-07-17  1:03 ` [PATCH RFC 10/12] x86/pvticketlock: keep count of blocked cpus Jeremy Fitzhardinge
2010-08-03  8:32   ` Peter Zijlstra
2010-08-03  8:32     ` Peter Zijlstra
2010-08-03  9:44     ` Nick Piggin
2010-08-03 15:45     ` Jeremy Fitzhardinge [this message]
2010-08-03 15:45       ` Jeremy Fitzhardinge
2010-07-17  1:03 ` [PATCH RFC 03/12] x86/ticketlock: Use C for __ticket_spin_unlock Jeremy Fitzhardinge
2010-07-20 15:38   ` [Xen-devel] " Konrad Rzeszutek Wilk
2010-07-20 15:38     ` Konrad Rzeszutek Wilk
2010-07-20 16:17     ` [Xen-devel] " Jeremy Fitzhardinge
2010-07-20 16:17       ` Jeremy Fitzhardinge
2010-08-06 17:47       ` [Xen-devel] " H. Peter Anvin
2010-08-06 17:47         ` H. Peter Anvin
2010-08-06 20:03         ` [Xen-devel] " Jeremy Fitzhardinge
2010-08-06 20:03           ` Jeremy Fitzhardinge
2010-07-17  1:03 ` [PATCH RFC 07/12] x86/spinlocks: replace pv spinlocks with pv ticketlocks Jeremy Fitzhardinge
2010-07-17  1:03 ` [PATCH RFC 05/12] x86/ticketlock: make __ticket_spin_lock common Jeremy Fitzhardinge
  -- strict thread matches above, loose matches on Subject: below --
2010-07-05 14:53 [PATCH RFC 10/12] x86/pvticketlock: keep count of blocked cpus 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=4C583996.1090805@goop.org \
    --to=jeremy@goop.org \
    --cc=JBeulich@novell.com \
    --cc=avi@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=npiggin@suse.de \
    --cc=peterz@infradead.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.