From: Ingo Molnar <mingo@elte.hu>
To: Gautham R Shenoy <ego@in.ibm.com>
Cc: rusty@rustcorp.com.au, torvalds@osdl.org, akpm@osdl.org,
linux-kernel@vger.kernel.org, arjan@linux.intel.com,
davej@redhat.com, vatsa@in.ibm.com, dipankar@in.ibm.com,
ashok.raj@intel.com
Subject: Re: [RFC][PATCH 0/4] Redesign cpu_hotplug locking.
Date: Thu, 24 Aug 2006 13:24:22 +0200 [thread overview]
Message-ID: <20060824112422.GA21121@elte.hu> (raw)
In-Reply-To: <20060824112749.GG2395@in.ibm.com>
* Gautham R Shenoy <ego@in.ibm.com> wrote:
> On Thu, Aug 24, 2006 at 12:34:12PM +0200, Ingo Molnar wrote:
> > Please add the appropriate lock_acquire()/lock_release() calls into the
> > new sleeping semaphore type. Just use the parameters that rwlocks use:
> >
> > #define rwlock_acquire(l, s, t, i) lock_acquire(l, s, t, 0, 2, i)
> > #define rwlock_acquire_read(l, s, t, i) lock_acquire(l, s, t, 2, 2, i)
>
> > and lockdep will allow recursive read-locking. You'll also need a
> > lockdep_init_map() call to register the lock with lockdep. Then your
> > locking scheme will be fully checked by lockdep too. (with your current
> > code the new lock type is not added to the lock dependency graph(s))
>
> I'm on it. :)
you'll also need to add a dep_map to the cpu_hotplug structure itself.
and i think this extension of lockdep to the new lock type will be
invariant with the per-cpu optimizations i suggested in the previous
mail: because it's only the scalability of cpu_hotplug_lock() that will
improve [dramatically], its locking semantics wont.
Ingo
next prev parent reply other threads:[~2006-08-24 11:32 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-24 10:26 [RFC][PATCH 0/4] Redesign cpu_hotplug locking Gautham R Shenoy
2006-08-24 10:34 ` Ingo Molnar
2006-08-24 11:27 ` Gautham R Shenoy
2006-08-24 11:24 ` Ingo Molnar [this message]
2006-08-24 16:17 ` Andrew Morton
2006-08-25 9:50 ` Dave Jones
2006-08-26 21:09 ` Linus Torvalds
2006-08-26 22:04 ` Andrew Morton
2006-08-27 6:11 ` Dipankar Sarma
2006-08-27 6:46 ` Andrew Morton
2006-08-27 7:11 ` Dipankar Sarma
2006-08-27 7:42 ` Andrew Morton
2006-08-27 8:57 ` Nick Piggin
2006-08-27 11:06 ` Dipankar Sarma
2006-08-27 17:21 ` Andrew Morton
2006-08-27 17:49 ` Dipankar Sarma
2006-08-27 18:01 ` Andrew Morton
2006-08-27 7:37 ` Dipankar Sarma
2006-08-27 7:57 ` Andrew Morton
2006-08-26 22:05 ` Ingo Molnar
2006-08-26 22:25 ` Andrew Morton
2006-08-28 2:37 ` Srivatsa Vaddagiri
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=20060824112422.GA21121@elte.hu \
--to=mingo@elte.hu \
--cc=akpm@osdl.org \
--cc=arjan@linux.intel.com \
--cc=ashok.raj@intel.com \
--cc=davej@redhat.com \
--cc=dipankar@in.ibm.com \
--cc=ego@in.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rusty@rustcorp.com.au \
--cc=torvalds@osdl.org \
--cc=vatsa@in.ibm.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.