[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20061215081138.4c51e7c5.akpm@osdl.org>
Date: Fri, 15 Dec 2006 08:11:38 -0800
From: Andrew Morton <akpm@...l.org>
To: Ingo Molnar <mingo@...e.hu>
Cc: linux-kernel@...r.kernel.org
Subject: Re: + schedule_on_each_cpu-use-preempt_disable.patch added to -mm
tree
On Fri, 15 Dec 2006 09:31:12 +0100
Ingo Molnar <mingo@...e.hu> wrote:
>
> * akpm@...l.org <akpm@...l.org> wrote:
>
> > - mutex_lock(&workqueue_mutex);
> > + preempt_disable(); /* CPU hotplug */
> > for_each_online_cpu(cpu) {
> > INIT_WORK(per_cpu_ptr(works, cpu), func);
> > __queue_work(per_cpu_ptr(keventd_wq->cpu_wq, cpu),
> > per_cpu_ptr(works, cpu));
> > }
> > - mutex_unlock(&workqueue_mutex);
> > + preempt_enable();
>
> Why not cpu_hotplug_lock()?
>
Because the workqueue code was explicitly switched over to per-subsystem
cpu-hotplug locking.
Because lock_cpu_hotplug() is a complete turkey, source of deadlocks and
overall bad idea.
This is actually a pretty simple problem. A subsystem has per-cpu reosurces,
and it needs to lock them while using them. duh. We know how to do that
sort of thing. But because the first implementation of lock_cpu_hotplug()
was conceived with magical properties, we seem to think we need to retain
magical properties. We don't...
-
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