On Thu, Apr 12, 2007 at 08:00:04PM +0400, Oleg Nesterov wrote:
> On 04/12, Srivatsa Vaddagiri wrote:
> >
> > On Tue, Apr 03, 2007 at 10:48:20PM +0530, Srivatsa Vaddagiri wrote:
> > > > Actually, we should do this before destroy_workqueue() calls
> > > > flush_workqueue().
> > > > Otherwise
On Thu, Apr 12, 2007 at 08:00:04PM +0400, Oleg Nesterov wrote:
On 04/12, Srivatsa Vaddagiri wrote:
On Tue, Apr 03, 2007 at 10:48:20PM +0530, Srivatsa Vaddagiri wrote:
Actually, we should do this before destroy_workqueue() calls
flush_workqueue().
Otherwise flush_cpu_workqueue()
On 04/12, Srivatsa Vaddagiri wrote:
>
> On Tue, Apr 03, 2007 at 10:48:20PM +0530, Srivatsa Vaddagiri wrote:
> > > Actually, we should do this before destroy_workqueue() calls
> > > flush_workqueue().
> > > Otherwise flush_cpu_workqueue() can hang forever in a similar manner.
> >
> > Yep. I guess
On Thu, Apr 12, 2007 at 07:52:20AM +0530, Srivatsa Vaddagiri wrote:
> I wonder if there is some value in "enforcing" an order in which
> processes get frozen i.e freeze A first before B. That may solve the
> deadlocks we have been discussing wrt kthread_stop and flush_workqueue
> as well.
>
> The
On Thu, Apr 12, 2007 at 07:52:20AM +0530, Srivatsa Vaddagiri wrote:
I wonder if there is some value in enforcing an order in which
processes get frozen i.e freeze A first before B. That may solve the
deadlocks we have been discussing wrt kthread_stop and flush_workqueue
as well.
The idea is
On 04/12, Srivatsa Vaddagiri wrote:
On Tue, Apr 03, 2007 at 10:48:20PM +0530, Srivatsa Vaddagiri wrote:
Actually, we should do this before destroy_workqueue() calls
flush_workqueue().
Otherwise flush_cpu_workqueue() can hang forever in a similar manner.
Yep. I guess these are a
On Tue, Apr 03, 2007 at 10:48:20PM +0530, Srivatsa Vaddagiri wrote:
> > Actually, we should do this before destroy_workqueue() calls
> > flush_workqueue().
> > Otherwise flush_cpu_workqueue() can hang forever in a similar manner.
>
> Yep. I guess these are a class of freezer deadlocks very
On Tue, Apr 03, 2007 at 10:48:20PM +0530, Srivatsa Vaddagiri wrote:
Actually, we should do this before destroy_workqueue() calls
flush_workqueue().
Otherwise flush_cpu_workqueue() can hang forever in a similar manner.
Yep. I guess these are a class of freezer deadlocks very similar to
On 04/04, Srivatsa Vaddagiri wrote:
>
> On Wed, Apr 04, 2007 at 07:28:28PM +0400, Oleg Nesterov wrote:
> >
> > worker_thread:
> >
> > for (;;) {
> > try_to_freeze();
> >
> > prepare_to_wait();
> > if (...)
> >
On 04/04, Srivatsa Vaddagiri wrote:
On Wed, Apr 04, 2007 at 07:28:28PM +0400, Oleg Nesterov wrote:
worker_thread:
for (;;) {
try_to_freeze();
prepare_to_wait();
if (...)
On Wed, Apr 04, 2007 at 07:28:28PM +0400, Oleg Nesterov wrote:
> I changed my mind :) The problem is general, I am starting to believe
> it is better to change kthread_stop().
yes i agree. Although is some cases like destroy_workqueue, we need to
mark the target thread non-freezable way before we
On 04/03, Srivatsa Vaddagiri wrote:
>
> On Tue, Apr 03, 2007 at 07:03:36PM +0400, Oleg Nesterov wrote:
>
> > is better to introduce a new helper for that, kthread_thaw_stop() or
> > something.
>
> Will think of that.
I changed my mind :) The problem is general, I am starting to believe
it is
On 04/03, Srivatsa Vaddagiri wrote:
On Tue, Apr 03, 2007 at 07:03:36PM +0400, Oleg Nesterov wrote:
is better to introduce a new helper for that, kthread_thaw_stop() or
something.
Will think of that.
I changed my mind :) The problem is general, I am starting to believe
it is better to
On Wed, Apr 04, 2007 at 07:28:28PM +0400, Oleg Nesterov wrote:
I changed my mind :) The problem is general, I am starting to believe
it is better to change kthread_stop().
yes i agree. Although is some cases like destroy_workqueue, we need to
mark the target thread non-freezable way before we
On Tue, Apr 03, 2007 at 07:03:36PM +0400, Oleg Nesterov wrote:
> I think it would be nice to do. I believe we can cleanup ksoftirqd()
> and migration_thread() as well (kill wait_to_die: loop). Probably it
I doubt whether we can kill it in migration_thread, since that is
another thread which is
On 04/03, Srivatsa Vaddagiri wrote:
>
> On Tue, Apr 03, 2007 at 03:47:29PM +0400, Oleg Nesterov wrote:
> >
> > for (;;) {
> > try_to_freeze();
> >
> > prepare_to_wait(>more_work, ,
> > TASK_INTERRUPTIBLE);
> > if
On Tue, Apr 03, 2007 at 03:47:29PM +0400, Oleg Nesterov wrote:
> I still think that wait_to_die + bind_cpu is unneeded complication.
> Why can't we do the following:
>
> static int worker_thread(void *__cwq)
> {
> ...
>
> for (;;) {
>
> On 04/02, Gautham R Shenoy wrote:
>
> Clean up workqueue.c from the perspective of freezer-based cpu-hotplug.
> This patch
I'll study these patches later, a couple of comments after the quick reading.
> This means that all non-singlethreaded workqueues *have* to
> be frozen to avoid any
On 04/02, Gautham R Shenoy wrote:
Clean up workqueue.c from the perspective of freezer-based cpu-hotplug.
This patch
I'll study these patches later, a couple of comments after the quick reading.
This means that all non-singlethreaded workqueues *have* to
be frozen to avoid any races.
On Tue, Apr 03, 2007 at 03:47:29PM +0400, Oleg Nesterov wrote:
I still think that wait_to_die + bind_cpu is unneeded complication.
Why can't we do the following:
static int worker_thread(void *__cwq)
{
...
for (;;) {
On 04/03, Srivatsa Vaddagiri wrote:
On Tue, Apr 03, 2007 at 03:47:29PM +0400, Oleg Nesterov wrote:
for (;;) {
try_to_freeze();
prepare_to_wait(cwq-more_work, wait,
TASK_INTERRUPTIBLE);
if
On Tue, Apr 03, 2007 at 07:03:36PM +0400, Oleg Nesterov wrote:
I think it would be nice to do. I believe we can cleanup ksoftirqd()
and migration_thread() as well (kill wait_to_die: loop). Probably it
I doubt whether we can kill it in migration_thread, since that is
another thread which is
Clean up workqueue.c from the perspective of freezer-based cpu-hotplug.
This patch
o Removes cpu_populated_map as cpu_online_map is safe to use.
o removes cwq_should_stop and uses kthread_should_stop instead.
o Reintroduces take_over_work from the worker_thread of a downed
cpu. This means that
Clean up workqueue.c from the perspective of freezer-based cpu-hotplug.
This patch
o Removes cpu_populated_map as cpu_online_map is safe to use.
o removes cwq_should_stop and uses kthread_should_stop instead.
o Reintroduces take_over_work from the worker_thread of a downed
cpu. This means that
24 matches
Mail list logo
