From: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org, linux-ia64@vger.kernel.org,
ptesarik@suse.cz, tee@sgi.com, holt@sgi.com,
peterz@infradead.org, mingo@elte.hu, linux-arch@vger.kernel.org
Subject: Re: [Patch V3 0/3] Enable irqs when waiting for rwlocks
Date: Tue, 2 Dec 2008 16:13:11 -0800 [thread overview]
Message-ID: <20081202161311.ae3376cb.akpm@linux-foundation.org> (raw)
In-Reply-To: <20081104122405.046233722@attica.americas.sgi.com>
On Tue, 04 Nov 2008 06:24:05 -0600
holt@sgi.com wrote:
> New in V3:
> * Handle rearrangement of some arch's include/asm directories.
>
> New in V2:
> * get rid of ugly #ifdef's in kernel/spinlock.h
> * convert __raw_{read|write}_lock_flags to an inline func
>
> SGI has observed that on large systems, interrupts are not serviced for
> a long period of time when waiting for a rwlock. The following patch
> series re-enables irqs while waiting for the lock, resembling the code
> which is already there for spinlocks.
>
> I only made the ia64 version, because the patch adds some overhead to
> the fast path. I assume there is currently no demand to have this for
> other architectures, because the systems are not so large. Of course,
> the possibility to implement raw_{read|write}_lock_flags for any
> architecture is still there.
>
The patches seem reasonable. I queued all three with the intention of
merging #1 and #2 into 2.6.29. At that stage, architectures can decide
whether or not they want to do this. I shall then spam Tony with #3 so
you can duke it out with him.
It's a bit regrettable to have different architectures behaving in
different ways. It would be interesting to toss an x86_64
implementation into the grinder, see if it causes any problems, see if
it produces any tangible benefits. Then other architectures might
follow. Or not, depending on the results ;)
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: holt@sgi.com
Cc: linux-kernel@vger.kernel.org, linux-ia64@vger.kernel.org,
ptesarik@suse.cz, tee@sgi.com, peterz@infradead.org,
mingo@elte.hu, linux-arch@vger.kernel.org
Subject: Re: [Patch V3 0/3] Enable irqs when waiting for rwlocks
Date: Tue, 2 Dec 2008 16:13:11 -0800 [thread overview]
Message-ID: <20081202161311.ae3376cb.akpm@linux-foundation.org> (raw)
Message-ID: <20081203001311.QKWpCiP2OINwiB3brWXMvsPWy-WBSRClj7_hVUI-j0k@z> (raw)
In-Reply-To: <20081104122405.046233722@attica.americas.sgi.com>
On Tue, 04 Nov 2008 06:24:05 -0600
holt@sgi.com wrote:
> New in V3:
> * Handle rearrangement of some arch's include/asm directories.
>
> New in V2:
> * get rid of ugly #ifdef's in kernel/spinlock.h
> * convert __raw_{read|write}_lock_flags to an inline func
>
> SGI has observed that on large systems, interrupts are not serviced for
> a long period of time when waiting for a rwlock. The following patch
> series re-enables irqs while waiting for the lock, resembling the code
> which is already there for spinlocks.
>
> I only made the ia64 version, because the patch adds some overhead to
> the fast path. I assume there is currently no demand to have this for
> other architectures, because the systems are not so large. Of course,
> the possibility to implement raw_{read|write}_lock_flags for any
> architecture is still there.
>
The patches seem reasonable. I queued all three with the intention of
merging #1 and #2 into 2.6.29. At that stage, architectures can decide
whether or not they want to do this. I shall then spam Tony with #3 so
you can duke it out with him.
It's a bit regrettable to have different architectures behaving in
different ways. It would be interesting to toss an x86_64
implementation into the grinder, see if it causes any problems, see if
it produces any tangible benefits. Then other architectures might
follow. Or not, depending on the results ;)
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: holt@sgi.com
Cc: linux-kernel@vger.kernel.org, linux-ia64@vger.kernel.org,
ptesarik@suse.cz, tee@sgi.com, peterz@infradead.org,
mingo@elte.hu, linux-arch@vger.kernel.org
Subject: Re: [Patch V3 0/3] Enable irqs when waiting for rwlocks
Date: Wed, 03 Dec 2008 00:13:11 +0000 [thread overview]
Message-ID: <20081202161311.ae3376cb.akpm@linux-foundation.org> (raw)
In-Reply-To: <20081104122405.046233722@attica.americas.sgi.com>
On Tue, 04 Nov 2008 06:24:05 -0600
holt@sgi.com wrote:
> New in V3:
> * Handle rearrangement of some arch's include/asm directories.
>
> New in V2:
> * get rid of ugly #ifdef's in kernel/spinlock.h
> * convert __raw_{read|write}_lock_flags to an inline func
>
> SGI has observed that on large systems, interrupts are not serviced for
> a long period of time when waiting for a rwlock. The following patch
> series re-enables irqs while waiting for the lock, resembling the code
> which is already there for spinlocks.
>
> I only made the ia64 version, because the patch adds some overhead to
> the fast path. I assume there is currently no demand to have this for
> other architectures, because the systems are not so large. Of course,
> the possibility to implement raw_{read|write}_lock_flags for any
> architecture is still there.
>
The patches seem reasonable. I queued all three with the intention of
merging #1 and #2 into 2.6.29. At that stage, architectures can decide
whether or not they want to do this. I shall then spam Tony with #3 so
you can duke it out with him.
It's a bit regrettable to have different architectures behaving in
different ways. It would be interesting to toss an x86_64
implementation into the grinder, see if it causes any problems, see if
it produces any tangible benefits. Then other architectures might
follow. Or not, depending on the results ;)
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: holt@sgi.com
Cc: linux-kernel@vger.kernel.org, linux-ia64@vger.kernel.org,
ptesarik@suse.cz, tee@sgi.com, holt@sgi.com,
peterz@infradead.org, mingo@elte.hu, linux-arch@vger.kernel.org
Subject: Re: [Patch V3 0/3] Enable irqs when waiting for rwlocks
Date: Tue, 2 Dec 2008 16:13:11 -0800 [thread overview]
Message-ID: <20081202161311.ae3376cb.akpm@linux-foundation.org> (raw)
In-Reply-To: <20081104122405.046233722@attica.americas.sgi.com>
On Tue, 04 Nov 2008 06:24:05 -0600
holt@sgi.com wrote:
> New in V3:
> * Handle rearrangement of some arch's include/asm directories.
>
> New in V2:
> * get rid of ugly #ifdef's in kernel/spinlock.h
> * convert __raw_{read|write}_lock_flags to an inline func
>
> SGI has observed that on large systems, interrupts are not serviced for
> a long period of time when waiting for a rwlock. The following patch
> series re-enables irqs while waiting for the lock, resembling the code
> which is already there for spinlocks.
>
> I only made the ia64 version, because the patch adds some overhead to
> the fast path. I assume there is currently no demand to have this for
> other architectures, because the systems are not so large. Of course,
> the possibility to implement raw_{read|write}_lock_flags for any
> architecture is still there.
>
The patches seem reasonable. I queued all three with the intention of
merging #1 and #2 into 2.6.29. At that stage, architectures can decide
whether or not they want to do this. I shall then spam Tony with #3 so
you can duke it out with him.
It's a bit regrettable to have different architectures behaving in
different ways. It would be interesting to toss an x86_64
implementation into the grinder, see if it causes any problems, see if
it produces any tangible benefits. Then other architectures might
follow. Or not, depending on the results ;)
next prev parent reply other threads:[~2008-12-03 0:13 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-04 12:24 [Patch V3 0/3] Enable irqs when waiting for rwlocks holt
2008-11-04 12:24 ` holt
2008-11-04 12:24 ` [Patch V3 1/3] Factor out #ifdefs from kernel/spinlock.c to LOCK_CONTENDED_FLAGS holt
2008-11-04 12:24 ` holt
2008-11-04 12:24 ` [Patch V3 2/3] Allow rwlocks to re-enable interrupts holt
2008-11-04 12:24 ` holt
2008-11-04 12:24 ` [Patch V3 3/3] ia64: implement interrupt-enabling rwlocks holt
2008-11-04 12:24 ` holt
2008-12-03 0:13 ` Andrew Morton [this message]
2008-12-03 0:13 ` [Patch V3 0/3] Enable irqs when waiting for rwlocks Andrew Morton
2008-12-03 0:13 ` Andrew Morton
2008-12-03 0:13 ` Andrew Morton
2008-12-03 11:37 ` Robin Holt
2008-12-03 11:37 ` Robin Holt
2008-12-03 12:25 ` Peter Zijlstra
2008-12-03 12:25 ` Peter Zijlstra
2008-12-03 12:36 ` Petr Tesarik
2008-12-03 12:36 ` Petr Tesarik
2008-12-03 12:36 ` Petr Tesarik
2008-12-03 12:44 ` Peter Zijlstra
2008-12-03 12:44 ` Peter Zijlstra
2008-12-03 12:44 ` Peter Zijlstra
2009-01-07 23:35 ` Andrew Morton
2009-01-07 23:35 ` Andrew Morton
2009-01-08 0:05 ` Luck, Tony
2009-01-08 0:05 ` Luck, Tony
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=20081202161311.ae3376cb.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=holt@sgi.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=ptesarik@suse.cz \
--cc=tee@sgi.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.