From: Paul Turner <pjt@google.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: "Luck, Tony" <tony.luck@intel.com>, Ken Chen <kenchen@google.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
Ralf Baechle <ralf@linux-mips.org>,
David Miller <davem@davemloft.net>
Subject: Re: [ia64] Question on __ARCH_WANT_UNLOCKED_CTXSW
Date: Fri, 16 Sep 2011 01:09:20 -0700 [thread overview]
Message-ID: <4E730430.7090608@google.com> (raw)
In-Reply-To: <1315940361.4226.17.camel@twins>
On 09/13/11 11:59, Peter Zijlstra wrote:
> On Wed, 2011-08-24 at 13:46 -0700, Luck, Tony wrote:
>>> happen to remember what the perceived benefit of using
>>> __ARCH_WANT_UNLOCKED_CTXSW was about?
>>
>> No - digging around the code hasn't rung any bells for me either.
>>
>> Perhaps just general goodness for not holding a lock for
>> longer than we need to? But that would imply some case where
>> someone else could do something useful by being able to grab
>> the lock when we drop it. About the only thing I can think
>> of is that it would allow tasks to be re-balanced just a
>> teeny bit earlier --- but re-balancing ought to be somewhat
>> rare, yes?
>
> Mostly yes, except remote wakeups, however that got a complete overhaul
> in 3.0. Instead of taking the remote rq->lock we now enqueue the task on
> a list and IPI the thing, then let the IPI do the remote enqueue and
> trigger the reschedule.
>
> So it might make sense to re-evaluate this on ia64 like Ken suggested..
> then again, who has a large ia64 box and is still willing to put time
> in?
Hum -- perhaps they'll come out of the woodwork if we just rip it out
(if they exist)
- Paul
prev parent reply other threads:[~2011-09-16 8:09 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-24 12:27 [ia64] Question on __ARCH_WANT_UNLOCKED_CTXSW Peter Zijlstra
2011-08-24 16:51 ` Ken Chen
2011-08-24 20:46 ` Luck, Tony
2011-09-13 18:59 ` Peter Zijlstra
2011-09-16 8:09 ` Paul Turner [this message]
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=4E730430.7090608@google.com \
--to=pjt@google.com \
--cc=davem@davemloft.net \
--cc=kenchen@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=ralf@linux-mips.org \
--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.