On 01/17, Srivatsa Vaddagiri wrote:
>
> On Wed, Jan 17, 2007 at 06:47:16PM +0300, Oleg Nesterov wrote:
> > > What do you mean by "currently" executing work? worker thread executing
> > > some work on the cpu? That is not possible, because all threads are
> > > frozen at this point. There cant be an
On Wed, Jan 17, 2007 at 06:47:16PM +0300, Oleg Nesterov wrote:
> Btw, I agree it is good to have a sleeping lock to protect cpu_online_map.
> But it should be separate from workqueue_mutex, and it is not needed for
> create/destroy/flush funcs.
Which is what lock_cpu_hotplug() attempted to provide
On Wed, Jan 17, 2007 at 06:47:16PM +0300, Oleg Nesterov wrote:
> > What do you mean by "currently" executing work? worker thread executing
> > some work on the cpu? That is not possible, because all threads are
> > frozen at this point. There cant be any ongoing flush_workxxx() as well
> > because
On 01/17, Srivatsa Vaddagiri wrote:
>
> On Tue, Jan 16, 2007 at 04:27:25PM +0300, Oleg Nesterov wrote:
> > > I meant issuing kthread_stop() in DOWN_PREPARE so that worker
> > > thread exits itself (much before CPU is actually brought down).
> >
> > Deadlock if work_struct re-queues itself.
>
> Ar
On Tue, Jan 16, 2007 at 04:27:25PM +0300, Oleg Nesterov wrote:
> > I meant issuing kthread_stop() in DOWN_PREPARE so that worker
> > thread exits itself (much before CPU is actually brought down).
>
> Deadlock if work_struct re-queues itself.
Are you referring to the problem you described here?
On 01/16, Srivatsa Vaddagiri wrote:
>
> On Mon, Jan 15, 2007 at 07:55:16PM +0300, Oleg Nesterov wrote:
> >
> > As I said already __create_workqueue() needs a fix, schedule_on_each_cpu()
> > is already broken, and should be fixed as well.
>
> __create_workqueue() creates worker threads for all onli
On Mon, Jan 15, 2007 at 07:55:16PM +0300, Oleg Nesterov wrote:
> > What if 'singlethread_cpu' dies?
>
> Still can't understand you. Probably you missed what singlethread_cpu is.
oops yes ..I had mistakenly thought that create_workqueue_thread() will
bind worker thread to singlethread_cpu for sing
On 01/15, Srivatsa Vaddagiri wrote:
>
> On Mon, Jan 15, 2007 at 03:54:01PM +0300, Oleg Nesterov wrote:
> > > - singlethread_cpu needs to be hotplug safe (broken currently)
> >
> > Why? Could you explain?
>
> What if 'singlethread_cpu' dies?
Still can't understand you. Probably you missed what si
On Mon, Jan 15, 2007 at 03:54:01PM +0300, Oleg Nesterov wrote:
> > - singlethread_cpu needs to be hotplug safe (broken currently)
>
> Why? Could you explain?
What if 'singlethread_cpu' dies?
> > - Any reason why cpu_populated_map is not modified on CPU_DEAD?
>
> Because CPU_DEAD/CPU_UP_CANCELED
On 01/15, Oleg Nesterov wrote:
>
> cpu_populated_map never shrinks, it only grows on CPU_UP_PREPARE.
__create_workqueue() should not use it. Needs a fix.
Oleg.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo i
On 01/15, Srivatsa Vaddagiri wrote:
>
> On Mon, Jan 15, 2007 at 02:54:10AM +0300, Oleg Nesterov wrote:
> > How about the pseudo-code below?
>
> Some quick comments:
>
> - singlethread_cpu needs to be hotplug safe (broken currently)
Why? Could you explain?
> - Any reason why cpu_populated_map is
On Mon, Jan 15, 2007 at 02:54:10AM +0300, Oleg Nesterov wrote:
> How about the pseudo-code below?
Some quick comments:
- singlethread_cpu needs to be hotplug safe (broken currently)
- Any reason why cpu_populated_map is not modified on CPU_DEAD?
- I feel more comfortable if workqueue_cpu_callba
How about the pseudo-code below?
workqueue_mutex is only used to protect "struct list_head workqueues",
all workqueue operations can run in parallel with cpuhotplug callback path.
take_over_work(), migrate_sequence, CPU_LOCK_ACQUIRE/RELEASE go away.
I'd like to make a couple of cleanups (and fix
On 01/09, Srivatsa Vaddagiri wrote:
>
> On Tue, Jan 09, 2007 at 07:38:15PM +0300, Oleg Nesterov wrote:
> > We can't do this. We should thaw cwq->thread (which was bound to the
> > dead CPU) to complete CPU_DEAD event. So we still need some changes.
>
> I noticed that, but I presumed kthread_stop()
On Tue, Jan 09, 2007 at 07:38:15PM +0300, Oleg Nesterov wrote:
> We can't do this. We should thaw cwq->thread (which was bound to the
> dead CPU) to complete CPU_DEAD event. So we still need some changes.
I noticed that, but I presumed kthread_stop() will post a wakeup which
will bring it out of f
On 01/09, Srivatsa Vaddagiri wrote:
>
> On Tue, Jan 09, 2007 at 06:07:55PM +0300, Oleg Nesterov wrote:
> > but at some point we should thaw processes, including cwq->thread which
> > should die.
>
> I am presuming we will thaw processes after all CPU_DEAD handlers have
> run.
>
> > So we are doin
On Tue, Jan 09, 2007 at 06:07:55PM +0300, Oleg Nesterov wrote:
> but at some point we should thaw processes, including cwq->thread which
> should die.
I am presuming we will thaw processes after all CPU_DEAD handlers have
run.
> So we are doing things like take_over_work() and this is the
> sourc
On 01/08, Andrew Morton wrote:
>
> That's not correct. freeze_processes() will freeze *all* processes. All
> of them are forced to enter refrigerator(). With the mysterious exception
> of some I/O-related kernel threads, which might need some thought.
Yes, and we can remove a dead CPU safely, t
On Tue, 9 Jan 2007 15:39:26 +0530
Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
> I just hope the latency of freeze_processes() is tolerable ..
It'll be roughly proportional to the number of processes, I guess: if we
have 100,000 processes (or threads) doing sleep(100) then yeah, it'll
take s
On Tue, Jan 09, 2007 at 01:51:52AM -0800, Andrew Morton wrote:
> > This thread makes absolutely -no- calls to try_to_freeze() in its lifetime.
>
> Looks like a bug to me. powerpc does appear to try to support the freezer.
>
> > 1. Does this mean that the thread can't be frozen? (lets say that th
On Tue, 9 Jan 2007 15:03:02 +0530
Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
> On Mon, Jan 08, 2007 at 09:26:56PM -0800, Andrew Morton wrote:
> > That's not correct. freeze_processes() will freeze *all* processes.
>
> I am not arguing whether all processes will be frozen. However my question
* Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
> This thread makes absolutely -no- calls to try_to_freeze() in its
> lifetime.
that's a plain bug. suspend will fail for example. A kernel thread
either needs to mark itself PF_NOFREEZE (which means it can be ignored
and zapped with impunity),
On Mon, Jan 08, 2007 at 09:26:56PM -0800, Andrew Morton wrote:
> That's not correct. freeze_processes() will freeze *all* processes.
I am not arguing whether all processes will be frozen. However my question was
on the freeze point. Let me ask the question with an example:
rtasd thread (arch/po
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> > I would be happy to be corrected if the above impression of
> > freeze_processes() is corrected ..
>
> It could be that the freezer needs a bit of work for this application.
> Obviously we're not interested in the handling of disk I/O, so we'd
>
On Tue, 9 Jan 2007 10:34:17 +0530
Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
> On Mon, Jan 08, 2007 at 03:54:28PM -0800, Andrew Morton wrote:
> > Furthermore I don't know which of these need to be tossed overboard if/when
> > we get around to using the task freezer for CPU hotplug synchronisati
On Mon, Jan 08, 2007 at 03:54:28PM -0800, Andrew Morton wrote:
> Furthermore I don't know which of these need to be tossed overboard if/when
> we get around to using the task freezer for CPU hotplug synchronisation.
> Hopefully, a lot of them. I don't really understand why we're continuing
> to st
Just a sad little note that I've utterly lost the plot on the workqueue
changes.
schedule_on_each_cpu-use-preempt_disable.patch
reimplement-flush_workqueue.patch
implement-flush_work.patch
implement-flush_work-sanity.patch
implement-flush_work_keventd.patch
flush_workqueue-use-preempt_disable-to-
27 matches
Mail list logo
