[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20060824112422.GA21121@elte.hu>
Date: Thu, 24 Aug 2006 13:24:22 +0200
From: Ingo Molnar <mingo@...e.hu>
To: Gautham R Shenoy <ego@...ibm.com>
Cc: rusty@...tcorp.com.au, torvalds@...l.org, akpm@...l.org,
linux-kernel@...r.kernel.org, arjan@...ux.intel.com,
davej@...hat.com, vatsa@...ibm.com, dipankar@...ibm.com,
ashok.raj@...el.com
Subject: Re: [RFC][PATCH 0/4] Redesign cpu_hotplug locking.
* Gautham R Shenoy <ego@...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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists