public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Nick Piggin <npiggin@kernel.dk>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Tejun Heo <tj@kernel.org>, Nick Piggin <npiggin@kernel.dk>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Jonathan Corbet <corbet@lwn.net>,
	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 21:38:58 +1000	[thread overview]
Message-ID: <20100826113858.GA6856@amd> (raw)
In-Reply-To: <1282817329.1975.486.camel@laptop>

On Thu, Aug 26, 2010 at 12:08:49PM +0200, Peter Zijlstra wrote:
> On Thu, 2010-08-26 at 11:49 +0200, Tejun Heo wrote:
> > If there's a pressing need, doing stop_machine for
> > onlining too is definitely an option. 
> 
> I would argue against that.. we should try and rid ourselves of
> stopmachine, not add more dependencies on it. If you want to sync
> against preempt_disable thingies synchronize_sched() is your friend.

I don't think it's that easy to do it in hotplug handlers.

Say take a brlock (not the best example because the write side
is a slowpath itself, but I could imagine better cases), then
you actually want to be able to prevent cpu online map from
changing for the entire period of a lock/unlock.

The lock/unlock is preempt disabled. synchronize_sched in the
plug handler will not really do anything, because there could
be subsequent write locks coming in from other CPUs at any
time during the handler, before or after synchronize_sched runs.

I think for CPU plug, stop_machine is reasonable (especially
considering it is required in unload, which means any frequent
amount of cpu plug activity already will require stop_machine to
run anyway).


  reply	other threads:[~2010-08-26 11:39 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
2010-08-26  9:50         ` Tejun Heo
2010-08-26 10:08         ` Peter Zijlstra
2010-08-26 11:38           ` Nick Piggin [this message]
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=20100826113858.GA6856@amd \
    --to=npiggin@kernel.dk \
    --cc=corbet@lwn.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=rusty@rustcorp.com.au \
    --cc=tj@kernel.org \
    --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