On Wed, Jan 03, 2007 at 08:26:57PM +0300, Oleg Nesterov wrote:
>
> I thought that these patches don't depend on each other, flush_work/workueue
> don't care where cpu-hotplug takes workqueue_mutex, in CPU_LOCK_ACQUIRE or in
> CPU_UP_PREPARE case (or CPU_DEAD/CPU_LOCK_RELEASE for unlock).
>
>
On 01/03, Gautham R Shenoy wrote:
>
> On Wed, Jan 03, 2007 at 07:34:59PM +0530, Gautham R Shenoy wrote:
> >
> > > handle-cpu_lock_acquire-and-cpu_lock_release-in-workqueue_cpu_callback.patch
> >
> > Again, this one ensures that workqueue_mutex is taken/released on
> >
On Wed, Jan 03, 2007 at 07:34:59PM +0530, Gautham R Shenoy wrote:
>
> > handle-cpu_lock_acquire-and-cpu_lock_release-in-workqueue_cpu_callback.patch
>
> Again, this one ensures that workqueue_mutex is taken/released on
> CPU_LOCK_ACQUIRE/CPU_LOCK_RELEASE events in the cpuhotplug callback
>
Hi Andrew,
Sorry, I am yet to check out Venki's and Oleg's patches as I
just returned from Vacation.
On Tue, Jan 02, 2007 at 04:27:27PM -0800, Andrew Morton wrote:
>
> I have a mental note that these:
>
> extend-notifier_call_chain-to-count-nr_calls-made.patch
>
Hi Andrew,
Sorry, I am yet to check out Venki's and Oleg's patches as I
just returned from Vacation.
On Tue, Jan 02, 2007 at 04:27:27PM -0800, Andrew Morton wrote:
I have a mental note that these:
extend-notifier_call_chain-to-count-nr_calls-made.patch
On Wed, Jan 03, 2007 at 07:34:59PM +0530, Gautham R Shenoy wrote:
handle-cpu_lock_acquire-and-cpu_lock_release-in-workqueue_cpu_callback.patch
Again, this one ensures that workqueue_mutex is taken/released on
CPU_LOCK_ACQUIRE/CPU_LOCK_RELEASE events in the cpuhotplug callback
function. So
On 01/03, Gautham R Shenoy wrote:
On Wed, Jan 03, 2007 at 07:34:59PM +0530, Gautham R Shenoy wrote:
handle-cpu_lock_acquire-and-cpu_lock_release-in-workqueue_cpu_callback.patch
Again, this one ensures that workqueue_mutex is taken/released on
CPU_LOCK_ACQUIRE/CPU_LOCK_RELEASE events
On Sat, 30 Dec 2006 19:10:31 +0300
Oleg Nesterov <[EMAIL PROTECTED]> wrote:
> "[PATCH 1/2] reimplement flush_workqueue()" fixed one race when CPU goes down
> while flush_cpu_workqueue() plays with it. But there is another problem, CPU
> can die before flush_workqueue() has a chance to call
On Sat, 30 Dec 2006 19:10:31 +0300
Oleg Nesterov [EMAIL PROTECTED] wrote:
[PATCH 1/2] reimplement flush_workqueue() fixed one race when CPU goes down
while flush_cpu_workqueue() plays with it. But there is another problem, CPU
can die before flush_workqueue() has a chance to call
"[PATCH 1/2] reimplement flush_workqueue()" fixed one race when CPU goes down
while flush_cpu_workqueue() plays with it. But there is another problem, CPU
can die before flush_workqueue() has a chance to call flush_cpu_workqueue().
In that case pending work_structs can migrate to CPU which was
[PATCH 1/2] reimplement flush_workqueue() fixed one race when CPU goes down
while flush_cpu_workqueue() plays with it. But there is another problem, CPU
can die before flush_workqueue() has a chance to call flush_cpu_workqueue().
In that case pending work_structs can migrate to CPU which was
11 matches
Mail list logo
