All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robin Holt <holt@sgi.com>
To: "Luck, Tony" <tony.luck@intel.com>
Cc: Petr Tesarik <ptesarik@suse.cz>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-ia64@vger.kernel.org" <linux-ia64@vger.kernel.org>
Subject: Re: [PATCH V2 0/2] enable irqs when waiting for rwlocks
Date: Mon, 03 Nov 2008 11:46:39 +0000	[thread overview]
Message-ID: <20081103114638.GD8483@sgi.com> (raw)
In-Reply-To: <57C9024A16AD2D4C97DC78E552063EA35A7ED9D3@orsmsx505.amr.corp.intel.com>

On Fri, Oct 31, 2008 at 01:22:56PM -0700, Luck, Tony wrote:
> > Any comments on my second patch series? Not even an Acked-by? Dislike of
> > the concept? Should I post it again?
> 
> Better response to interrupts is good, but it comes at the
> cost of longer latency acquiring the lock (in the case where
> an interrupt happens while we are waiting for the lock, and
> the lock is freed while we are off executing the interrupt
> handler).
> 
> Any suggestions on how to measure the trade-off here?  Possibly
> it doesn't matter because this may only be significant when
> the lock is heavily contended and you are probably aleady
> hosed in this case.

Just a few years of experiencal evidence.  The equivalent of this patch
has been in the SuSE SLES10 kernel for years and not been detected as
being negative.

Sorry I don't have more detail.  The person at SGI who first detected
this problem has long since left, and actually passed away from an
aneurysm a couple years ago.  The first version of the patch was in our
one-off kernel based on Redhat's 2.4 kernel.  The patch was not pushed
to SuSE and the community for SLES9.  It was in SLES10, but I can not
find our internal tracking tool's record of it (searching is failing me
this morning).  Without that, I have not been able to find why it was
not pushed to the community.

Thanks,
Robin

WARNING: multiple messages have this Message-ID (diff)
From: Robin Holt <holt@sgi.com>
To: "Luck, Tony" <tony.luck@intel.com>
Cc: Petr Tesarik <ptesarik@suse.cz>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-ia64@vger.kernel.org" <linux-ia64@vger.kernel.org>
Subject: Re: [PATCH V2 0/2] enable irqs when waiting for rwlocks
Date: Mon, 3 Nov 2008 05:46:39 -0600	[thread overview]
Message-ID: <20081103114638.GD8483@sgi.com> (raw)
In-Reply-To: <57C9024A16AD2D4C97DC78E552063EA35A7ED9D3@orsmsx505.amr.corp.intel.com>

On Fri, Oct 31, 2008 at 01:22:56PM -0700, Luck, Tony wrote:
> > Any comments on my second patch series? Not even an Acked-by? Dislike of
> > the concept? Should I post it again?
> 
> Better response to interrupts is good, but it comes at the
> cost of longer latency acquiring the lock (in the case where
> an interrupt happens while we are waiting for the lock, and
> the lock is freed while we are off executing the interrupt
> handler).
> 
> Any suggestions on how to measure the trade-off here?  Possibly
> it doesn't matter because this may only be significant when
> the lock is heavily contended and you are probably aleady
> hosed in this case.

Just a few years of experiencal evidence.  The equivalent of this patch
has been in the SuSE SLES10 kernel for years and not been detected as
being negative.

Sorry I don't have more detail.  The person at SGI who first detected
this problem has long since left, and actually passed away from an
aneurysm a couple years ago.  The first version of the patch was in our
one-off kernel based on Redhat's 2.4 kernel.  The patch was not pushed
to SuSE and the community for SLES9.  It was in SLES10, but I can not
find our internal tracking tool's record of it (searching is failing me
this morning).  Without that, I have not been able to find why it was
not pushed to the community.

Thanks,
Robin

  reply	other threads:[~2008-11-03 11:46 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-23 15:57 [PATCH V2 0/2] enable irqs when waiting for rwlocks Petr Tesarik
2008-10-23 15:57 ` Petr Tesarik
2008-10-23 16:06 ` [PATCH V2 1/3] Factor out #ifdef's from kernel/spinlock.c to Petr Tesarik
2008-10-23 16:06   ` [PATCH V2 1/3] Factor out #ifdef's from kernel/spinlock.c to LOCK_CONTENDED_FLAGS Petr Tesarik
2008-11-27 15:32   ` [PATCH V2 1/3] Factor out #ifdef's from kernel/spinlock.c to Peter Zijlstra
2008-11-27 15:32     ` [PATCH V2 1/3] Factor out #ifdef's from kernel/spinlock.c to LOCK_CONTENDED_FLAGS Peter Zijlstra
2008-10-23 16:06 ` [PATCH V2 2/3] Allow rwlocks to re-enable interrupts Petr Tesarik
2008-10-23 16:06   ` Petr Tesarik
2008-11-27 15:33   ` Peter Zijlstra
2008-11-27 15:33     ` Peter Zijlstra
2008-10-31  8:52 ` [PATCH V2 0/2] enable irqs when waiting for rwlocks Petr Tesarik
2008-10-31  8:52   ` Petr Tesarik
2008-10-31 20:22   ` Luck, Tony
2008-10-31 20:22     ` Luck, Tony
2008-11-03 11:46     ` Robin Holt [this message]
2008-11-03 11:46       ` Robin Holt
2008-11-03 21:47       ` Luck, Tony
2008-11-03 21:47         ` Luck, Tony
2008-11-05  9:54         ` Petr Tesarik
2008-11-05  9:54           ` Petr Tesarik

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=20081103114638.GD8483@sgi.com \
    --to=holt@sgi.com \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ptesarik@suse.cz \
    --cc=tony.luck@intel.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.