From: Tejun Heo <tj@kernel.org>
To: Nick Piggin <npiggin@kernel.dk>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Jonathan Corbet <corbet@lwn.net>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Rusty Russell <rusty@rustcorp.com.au>,
Al Viro <viro@zeniv.linux.org.uk>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] lglock: make lg_lock_global() actually lock globally
Date: Thu, 26 Aug 2010 11:49:43 +0200 [thread overview]
Message-ID: <4C7638B7.9060306@kernel.org> (raw)
In-Reply-To: <20100826094613.GA6411@amd>
Hello,
On 08/26/2010 11:46 AM, Nick Piggin wrote:
> Oh, I thought we quiesce / preempt all online cpus before adding
> another one. That sucks if we don't because then you need a big
> heavy get_online_cpus when a simple preempt_disable would have
> worked.
>
> Why is that? Don't tell me realtime people want some latency "guarantee"
> while onlining CPUs? :)
Probably similar rationale of not doing stop_machine() on module
unload, I suppose. Onlining something is usually considered hotter
path than offlining. Performance penalty caused by the difference
between possible and online cpumask or cpu onlining probably only
matters for very large machines and on those machines stop-machine is
very expensive. If there's a pressing need, doing stop_machine for
onlining too is definitely an option.
>> So, yeah, given that there's no cpu notifier implemented, the use of
>> for_each_online_cpu for brlock seems fishy to me. It probably should
>> use for_each_possible_cpu().
>
> It should if that's the case, yes.
IMHO, in most configurations the difference between possible and
online cpumasks doesn't matter much (they're the same during normal
operation), so just using possible cpumask should be fine. It's
already a pretty heavy path, right?
Thanks.
--
tejun
next prev parent reply other threads:[~2010-08-26 9:55 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-25 19:28 [PATCH] lglock: make lg_lock_global() actually lock globally Jonathan Corbet
2010-08-25 20:00 ` Linus Torvalds
2010-08-25 20:16 ` Jonathan Corbet
2010-08-26 4:23 ` Nick Piggin
2010-08-26 8:55 ` Tejun Heo
2010-08-26 9:46 ` Nick Piggin
2010-08-26 9:49 ` Tejun Heo [this message]
2010-08-26 9:50 ` Tejun Heo
2010-08-26 10:08 ` Peter Zijlstra
2010-08-26 11:38 ` Nick Piggin
2010-08-26 11:45 ` Peter Zijlstra
2010-08-26 11:49 ` Peter Zijlstra
2010-08-27 5:51 ` Nick Piggin
2010-08-27 7:57 ` Peter Zijlstra
2010-08-27 7:59 ` Peter Zijlstra
2010-08-26 10:08 ` Peter Zijlstra
-- strict thread matches above, loose matches on Subject: below --
2010-09-08 22:54 Jonathan Corbet
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=4C7638B7.9060306@kernel.org \
--to=tj@kernel.org \
--cc=a.p.zijlstra@chello.nl \
--cc=corbet@lwn.net \
--cc=linux-kernel@vger.kernel.org \
--cc=npiggin@kernel.dk \
--cc=rusty@rustcorp.com.au \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox