On Wed, Feb 21, 2007 at 05:30:10PM +0300, Oleg Nesterov wrote:
> Agreed. Note that we don't need the new "del_work". It is always safe to
> use cancel_work_sync() if we know that the workqueue is frozen, it won't
> block. We can also do
>
> if (!cancel_delayed_work())
>
On Wed, Feb 21, 2007 at 05:30:10PM +0300, Oleg Nesterov wrote:
> On 02/21, Srivatsa Vaddagiri wrote:
> >
> > On Tue, Feb 20, 2007 at 11:09:36PM +0300, Oleg Nesterov wrote:
> > > > Which caller are you referring to here? Maybe we can decide on the
> > > > option after we see the users of
On 02/21, Srivatsa Vaddagiri wrote:
>
> On Tue, Feb 20, 2007 at 11:09:36PM +0300, Oleg Nesterov wrote:
> > > Which caller are you referring to here? Maybe we can decide on the
> > > option after we see the users of flush_workqueue() in DOWN_PREPARE.
> >
> > mm/slab.c:cpuup_callback()
>
> The
On 02/21, Srivatsa Vaddagiri wrote:
On Tue, Feb 20, 2007 at 11:09:36PM +0300, Oleg Nesterov wrote:
Which caller are you referring to here? Maybe we can decide on the
option after we see the users of flush_workqueue() in DOWN_PREPARE.
mm/slab.c:cpuup_callback()
The
On Wed, Feb 21, 2007 at 05:30:10PM +0300, Oleg Nesterov wrote:
On 02/21, Srivatsa Vaddagiri wrote:
On Tue, Feb 20, 2007 at 11:09:36PM +0300, Oleg Nesterov wrote:
Which caller are you referring to here? Maybe we can decide on the
option after we see the users of flush_workqueue() in
On Wed, Feb 21, 2007 at 05:30:10PM +0300, Oleg Nesterov wrote:
Agreed. Note that we don't need the new del_work. It is always safe to
use cancel_work_sync() if we know that the workqueue is frozen, it won't
block. We can also do
if (!cancel_delayed_work())
On Tue, Feb 20, 2007 at 11:09:36PM +0300, Oleg Nesterov wrote:
> > Which caller are you referring to here? Maybe we can decide on the
> > option after we see the users of flush_workqueue() in DOWN_PREPARE.
>
> mm/slab.c:cpuup_callback()
The cancel_rearming_delayed_work, if used as it is in
On 02/20, Srivatsa Vaddagiri wrote:
>
> On Sun, Feb 18, 2007 at 12:59:28AM +0300, Oleg Nesterov wrote:
> > Before you begin. You are doing CPU_DOWN_PREPARE after freeze_processes().
> > Not good. This makes impossible to do flush_workueue() at CPU_DOWN_PREPARE
> > stage, we have callers.
>
> We
On Sun, Feb 18, 2007 at 12:59:28AM +0300, Oleg Nesterov wrote:
> Before you begin. You are doing CPU_DOWN_PREPARE after freeze_processes().
> Not good. This makes impossible to do flush_workueue() at CPU_DOWN_PREPARE
> stage, we have callers.
We have few solutions to deal with this:
a. Mark such
On Sun, Feb 18, 2007 at 12:59:28AM +0300, Oleg Nesterov wrote:
Before you begin. You are doing CPU_DOWN_PREPARE after freeze_processes().
Not good. This makes impossible to do flush_workueue() at CPU_DOWN_PREPARE
stage, we have callers.
We have few solutions to deal with this:
a. Mark such
On 02/20, Srivatsa Vaddagiri wrote:
On Sun, Feb 18, 2007 at 12:59:28AM +0300, Oleg Nesterov wrote:
Before you begin. You are doing CPU_DOWN_PREPARE after freeze_processes().
Not good. This makes impossible to do flush_workueue() at CPU_DOWN_PREPARE
stage, we have callers.
We have few
On Tue, Feb 20, 2007 at 11:09:36PM +0300, Oleg Nesterov wrote:
Which caller are you referring to here? Maybe we can decide on the
option after we see the users of flush_workqueue() in DOWN_PREPARE.
mm/slab.c:cpuup_callback()
The cancel_rearming_delayed_work, if used as it is in
On 02/17, Srivatsa Vaddagiri wrote:
>
> Yeah, thats what I thought. We will try to split it to the extent
> possible in the next iteration.
Before you begin. You are doing CPU_DOWN_PREPARE after freeze_processes().
Not good. This makes impossible to do flush_workueue() at CPU_DOWN_PREPARE
stage,
On 02/17, Srivatsa Vaddagiri wrote:
Yeah, thats what I thought. We will try to split it to the extent
possible in the next iteration.
Before you begin. You are doing CPU_DOWN_PREPARE after freeze_processes().
Not good. This makes impossible to do flush_workueue() at CPU_DOWN_PREPARE
stage, we
On Sat, Feb 17, 2007 at 02:59:39AM +0300, Oleg Nesterov wrote:
> In that case (all processes are frozen when workqueue_cpu_callback()
> calls cleanup_workqueue_thread()) I agree, it is better to just use
> kthread_stop/kthread_should_stop.
Great, thanks!
> This also means that probably it won't
On 02/16, Srivatsa Vaddagiri wrote:
>
> Note with the change proposed in refrigerator, we can avoid
> CPU_DEAD_KILL_THREADS and do all cleanup in CPU_DEAD itself.
In that case (all processes are frozen when workqueue_cpu_callback()
calls cleanup_workqueue_thread()) I agree, it is better to just
On 02/16, Srivatsa Vaddagiri wrote:
>
> 2.6.20-mm1 (cwq->should_stop)
> =
>
> static void cleanup_workqueue_thread(struct cpu_workqueue_struct *cwq, int
> cpu)
> {
> struct wq_barrier barr;
> int alive = 0;
>
> spin_lock_irq(>lock);
>
On Fri, Feb 16, 2007 at 06:33:21PM +0300, Oleg Nesterov wrote:
> I take my words back. It is not "ugly" any longer because with this change
> we don't do kthread_stop()->wakeup_process() while cwq->thread may sleep in
> work->func(). Still I don't see (ok, I am biased and probably wrong, please
>
On 02/16, Srivatsa Vaddagiri wrote:
>
> On Wed, Feb 14, 2007 at 11:09:04PM +0300, Oleg Nesterov wrote:
> > What else you don't like? Why do you want to remove cwq_should_stop() and
> > restore an ugly (ugly for workqueue.c) kthread_stop/kthread_should_stop() ?
>
> What is ugly abt kthread_stop in
On 02/16, Srivatsa Vaddagiri wrote:
On Wed, Feb 14, 2007 at 11:09:04PM +0300, Oleg Nesterov wrote:
What else you don't like? Why do you want to remove cwq_should_stop() and
restore an ugly (ugly for workqueue.c) kthread_stop/kthread_should_stop() ?
What is ugly abt kthread_stop in
On Fri, Feb 16, 2007 at 06:33:21PM +0300, Oleg Nesterov wrote:
I take my words back. It is not ugly any longer because with this change
we don't do kthread_stop()-wakeup_process() while cwq-thread may sleep in
work-func(). Still I don't see (ok, I am biased and probably wrong, please
correct
On 02/16, Srivatsa Vaddagiri wrote:
2.6.20-mm1 (cwq-should_stop)
=
static void cleanup_workqueue_thread(struct cpu_workqueue_struct *cwq, int
cpu)
{
struct wq_barrier barr;
int alive = 0;
spin_lock_irq(cwq-lock);
if
On 02/16, Srivatsa Vaddagiri wrote:
Note with the change proposed in refrigerator, we can avoid
CPU_DEAD_KILL_THREADS and do all cleanup in CPU_DEAD itself.
In that case (all processes are frozen when workqueue_cpu_callback()
calls cleanup_workqueue_thread()) I agree, it is better to just use
On Sat, Feb 17, 2007 at 02:59:39AM +0300, Oleg Nesterov wrote:
In that case (all processes are frozen when workqueue_cpu_callback()
calls cleanup_workqueue_thread()) I agree, it is better to just use
kthread_stop/kthread_should_stop.
Great, thanks!
This also means that probably it won't be
On Wed, Feb 14, 2007 at 11:09:04PM +0300, Oleg Nesterov wrote:
> What else you don't like? Why do you want to remove cwq_should_stop() and
> restore an ugly (ugly for workqueue.c) kthread_stop/kthread_should_stop() ?
What is ugly abt kthread_stop in workqueue.c?
I feel it is nice if the cleanup
On Wed, Feb 14, 2007 at 11:09:04PM +0300, Oleg Nesterov wrote:
What else you don't like? Why do you want to remove cwq_should_stop() and
restore an ugly (ugly for workqueue.c) kthread_stop/kthread_should_stop() ?
What is ugly abt kthread_stop in workqueue.c?
I feel it is nice if the cleanup is
On 02/14, Srivatsa Vaddagiri wrote:
>
> On Wed, Feb 14, 2007 at 08:13:05PM +0530, Gautham R Shenoy wrote:
> > + switch (action) {
> > + case CPU_UP_PREPARE:
> > + /* Create a new workqueue thread for it. */
> > + list_for_each_entry(wq, , list) {
>
> Its probably safe to
On 02/14, Gautham R Shenoy wrote:
>
> This patch reverts all the recent workqueue hacks added to make it
> hotplug safe.
In my opinion these hacks are cleanups :)
Ok. If we use freezer then yes, we can remove cpu_populated_map and just
use for_each_online_cpu(). This is easy and good.
What
On Wed, Feb 14, 2007 at 08:13:05PM +0530, Gautham R Shenoy wrote:
> + switch (action) {
> + case CPU_UP_PREPARE:
> + /* Create a new workqueue thread for it. */
> + list_for_each_entry(wq, , list) {
Its probably safe to take the workqueue (spin) lock here (and
On Wed, Feb 14, 2007 at 08:13:05PM +0530, Gautham R Shenoy wrote:
> This patch reverts all the recent workqueue hacks added to make it
> hotplug safe.
Oleg,
This patch probably needs review for any races we may have
missed to account for. Also we have considered only workqueue.c
This patch reverts all the recent workqueue hacks added to make it
hotplug safe.
Signed-off-by : Srivatsa Vaddagiri <[EMAIL PROTECTED]>
Signed-off-by : Gautham R Shenoy <[EMAIL PROTECTED]>
kernel/workqueue.c | 225 +++--
1 files changed, 98
This patch reverts all the recent workqueue hacks added to make it
hotplug safe.
Signed-off-by : Srivatsa Vaddagiri [EMAIL PROTECTED]
Signed-off-by : Gautham R Shenoy [EMAIL PROTECTED]
kernel/workqueue.c | 225 +++--
1 files changed, 98
On Wed, Feb 14, 2007 at 08:13:05PM +0530, Gautham R Shenoy wrote:
This patch reverts all the recent workqueue hacks added to make it
hotplug safe.
Oleg,
This patch probably needs review for any races we may have
missed to account for. Also we have considered only workqueue.c present
On Wed, Feb 14, 2007 at 08:13:05PM +0530, Gautham R Shenoy wrote:
+ switch (action) {
+ case CPU_UP_PREPARE:
+ /* Create a new workqueue thread for it. */
+ list_for_each_entry(wq, workqueues, list) {
Its probably safe to take the workqueue (spin) lock here
On 02/14, Gautham R Shenoy wrote:
This patch reverts all the recent workqueue hacks added to make it
hotplug safe.
In my opinion these hacks are cleanups :)
Ok. If we use freezer then yes, we can remove cpu_populated_map and just
use for_each_online_cpu(). This is easy and good.
What else
On 02/14, Srivatsa Vaddagiri wrote:
On Wed, Feb 14, 2007 at 08:13:05PM +0530, Gautham R Shenoy wrote:
+ switch (action) {
+ case CPU_UP_PREPARE:
+ /* Create a new workqueue thread for it. */
+ list_for_each_entry(wq, workqueues, list) {
Its probably safe to
36 matches
Mail list logo
