From: Ingo Molnar <mingo@elte.hu>
To: Ashok Raj <ashok.raj@intel.com>
Cc: Linus Torvalds <torvalds@osdl.org>,
Srivatsa Vaddagiri <vatsa@in.ibm.com>,
Arjan van de Ven <arjan@linux.intel.com>,
Dave Jones <davej@redhat.com>,
Chuck Ebbert <76306.1226@compuserve.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@osdl.org>
Subject: Re: [patch] Reorganize the cpufreq cpu hotplug locking to not be totally bizare
Date: Sat, 29 Jul 2006 15:45:27 +0200 [thread overview]
Message-ID: <20060729134527.GA10899@elte.hu> (raw)
In-Reply-To: <20060727103811.A29962@unix-os.sc.intel.com>
* Ashok Raj <ashok.raj@intel.com> wrote:
> On Thu, Jul 27, 2006 at 03:40:49AM +0200, Ingo Molnar wrote:
> >
> > * Linus Torvalds <torvalds@osdl.org> wrote:
> >
> > > But I agree with Arjan - I think the fundamental problem is that cpu
> > > hotplug locking is just is fundamentally badly designed as-is. There's
> > > really very little point to making it a _lock_ per se, since most
> > > people really want more of a "I'm using this CPU, don't try to remove
> > > it right now" thing which is more of a ref-counting-like issue.
> >
> > we'd also need a facility to wait on that refcount - i.e. a waitqueue.
> > Which means we'd have a "refcount + waitqueue", which is equivalent to a
> > "recursive, sleeping read-lock", where the write-side could be used as a
> > simple facility to "wait for all readers to go away and block new
> > readers from entering the critical sections". [which type of lock Linux
> > does not have right now. rwsems come the closest but they dont recurse.]
>
> sounds like some varient of conditional variables, caveat might be
> that new readers permitted if in the same call thread/cpu?
well, i'd just call it a recursive rwsem. (sure, you can express it via
condition variables, but just about any locking method can be expressed
via them.)
> > Also, the hotplug lock is global right now which is pretty unscalable,
> > so the rw-mutex should also be per-CPU, and the hotplug locking API
> > should be changed to something like:
> >
> > cpu = cpu_hotplug_lock();
>
> so this is sort of like the get_cpu()/put_cpu() interface that does
> preempt_disable() + get current cpu.
the API is similar - behavior is different in that the 'per-cpu lock'
i'm talking about _does_ allow preemption and migration to another CPU.
Ingo
next prev parent reply other threads:[~2006-07-29 13:52 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-25 0:21 remove cpu hotplug bustification in cpufreq Chuck Ebbert
2006-07-25 0:59 ` Linus Torvalds
2006-07-25 15:06 ` Erik Mouw
2006-07-25 18:54 ` Ingo Molnar
2006-07-25 19:30 ` Arjan van de Ven
2006-07-25 20:57 ` Linus Torvalds
2006-07-26 13:40 ` [patch] Reorganize the cpufreq cpu hotplug locking to not be totally bizare Arjan van de Ven
2006-07-26 15:51 ` Dave Jones
2006-07-26 17:09 ` Linus Torvalds
2006-07-26 19:42 ` Arjan van de Ven
2006-07-26 20:22 ` Linus Torvalds
2006-07-26 20:58 ` Srivatsa Vaddagiri
2006-07-26 21:29 ` Linus Torvalds
2006-07-26 21:38 ` Arjan van de Ven
2006-07-27 1:40 ` Ingo Molnar
2006-07-27 17:38 ` Ashok Raj
2006-07-29 13:45 ` Ingo Molnar [this message]
2006-07-26 21:15 ` Ashok Raj
2006-07-27 19:29 ` Langsdorf, Mark
2006-07-28 13:50 ` Andi Kleen
2006-07-28 17:09 ` Langsdorf, Mark
2006-07-26 20:42 ` Srivatsa Vaddagiri
2006-07-26 21:03 ` Arjan van de Ven
2006-07-26 21:21 ` Srivatsa Vaddagiri
2006-07-26 21:33 ` Rafael J. Wysocki
2006-07-26 21:33 ` Andrew Morton
2006-07-26 22:35 ` Sanjoy Mahajan
2006-07-26 22:44 ` Arjan van de Ven
2006-07-25 20:46 ` remove cpu hotplug bustification in cpufreq Dave Jones
2006-07-25 20:59 ` Linus Torvalds
2006-07-26 17:12 ` Russell King
2006-07-26 17:53 ` Dave Jones
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=20060729134527.GA10899@elte.hu \
--to=mingo@elte.hu \
--cc=76306.1226@compuserve.com \
--cc=akpm@osdl.org \
--cc=arjan@linux.intel.com \
--cc=ashok.raj@intel.com \
--cc=davej@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).