On Mon, Apr 23, 2007 at 10:39:56PM +0400, Oleg Nesterov wrote:
> On 04/23, Gautham R Shenoy wrote:
> >
> > On Sat, Apr 21, 2007 at 01:12:09AM +0400, Oleg Nesterov wrote:
> > > On 04/19, Gautham R Shenoy wrote:
> > > >
> > > > @@ -63,12 +74,16 @@ void refrigerator(void)
> > > >
On 04/23, Gautham R Shenoy wrote:
>
> On Sat, Apr 21, 2007 at 01:12:09AM +0400, Oleg Nesterov wrote:
> > On 04/19, Gautham R Shenoy wrote:
> > >
> > > @@ -63,12 +74,16 @@ void refrigerator(void)
> > > recalc_sigpending(); /* We sent fake signal, clean it up */
> > >
On Sat, Apr 21, 2007 at 01:12:09AM +0400, Oleg Nesterov wrote:
> On 04/19, Gautham R Shenoy wrote:
> >
> > @@ -63,12 +74,16 @@ void refrigerator(void)
> > recalc_sigpending(); /* We sent fake signal, clean it up */
> > spin_unlock_irq(>sighand->siglock);
> >
> > + task_lock(current);
>
On Sat, Apr 21, 2007 at 01:12:09AM +0400, Oleg Nesterov wrote:
On 04/19, Gautham R Shenoy wrote:
@@ -63,12 +74,16 @@ void refrigerator(void)
recalc_sigpending(); /* We sent fake signal, clean it up */
spin_unlock_irq(current-sighand-siglock);
+ task_lock(current);
On 04/23, Gautham R Shenoy wrote:
On Sat, Apr 21, 2007 at 01:12:09AM +0400, Oleg Nesterov wrote:
On 04/19, Gautham R Shenoy wrote:
@@ -63,12 +74,16 @@ void refrigerator(void)
recalc_sigpending(); /* We sent fake signal, clean it up */
spin_unlock_irq(current-sighand-siglock);
On Mon, Apr 23, 2007 at 10:39:56PM +0400, Oleg Nesterov wrote:
On 04/23, Gautham R Shenoy wrote:
On Sat, Apr 21, 2007 at 01:12:09AM +0400, Oleg Nesterov wrote:
On 04/19, Gautham R Shenoy wrote:
@@ -63,12 +74,16 @@ void refrigerator(void)
recalc_sigpending(); /* We sent
Hi!
> > Of course, running try_to_freeze() in kthread_stop() would be very wrong,
> > so we'd actually need to do it in callers, preferably via a new
> > kthread_stop_freezeable() wrapper.
> >
> Well, even then we'll need to ensure that a thread would not call
> kthread_stop_freezeable() with
Hi!
Of course, running try_to_freeze() in kthread_stop() would be very wrong,
so we'd actually need to do it in callers, preferably via a new
kthread_stop_freezeable() wrapper.
Well, even then we'll need to ensure that a thread would not call
kthread_stop_freezeable() with any locks
On Friday, 20 April 2007 23:20, Oleg Nesterov wrote:
> On 04/20, Gautham R Shenoy wrote:
> >
> > On Fri, Apr 20, 2007 at 10:54:36AM +0200, Rafael J. Wysocki wrote:
> > >
> > > Hmm, can't we do something like this instead:
> > >
> > > ---
> > > kernel/kthread.c | 10 ++
> > > 1 file
On 04/20, Gautham R Shenoy wrote:
>
> On Fri, Apr 20, 2007 at 10:54:36AM +0200, Rafael J. Wysocki wrote:
> >
> > Hmm, can't we do something like this instead:
> >
> > ---
> > kernel/kthread.c | 10 ++
> > 1 file changed, 10 insertions(+)
> >
> > Index:
On 04/19, Gautham R Shenoy wrote:
>
> @@ -63,12 +74,16 @@ void refrigerator(void)
> recalc_sigpending(); /* We sent fake signal, clean it up */
> spin_unlock_irq(>sighand->siglock);
>
> + task_lock(current);
> for (;;) {
>
On Friday, 20 April 2007 20:31, Ingo Molnar wrote:
>
> * Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > > > I mean, we already have four of them (PF_NOFREEZE, PF_FROZEN,
> > > > PF_FREEZER_SKIP, TIF_FREEZE), and you will need to introduce two
> > > > more for the freezer-based CPU hotplug, so
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> > > I mean, we already have four of them (PF_NOFREEZE, PF_FROZEN,
> > > PF_FREEZER_SKIP, TIF_FREEZE), and you will need to introduce two
> > > more for the freezer-based CPU hotplug, so if yet another one is
> > > needed, that will make up almost a
On Fri, 20 Apr 2007 17:56:09 +0530
Gautham R Shenoy <[EMAIL PROTECTED]> wrote:
> > I mean, we already have four of them (PF_NOFREEZE, PF_FROZEN,
> > PF_FREEZER_SKIP, TIF_FREEZE), and you will need to introduce two more for
> > the freezer-based CPU hotplug, so if yet another one is needed, that
On Friday, 20 April 2007 14:26, Gautham R Shenoy wrote:
> On Fri, Apr 20, 2007 at 01:59:29PM +0200, Rafael J. Wysocki wrote:
> >
> > Actually, I thought about it for a while. The thread that is going to stop
> > another one may temporarily mark itself as freezable in all cases, which
> > will
On Fri, Apr 20, 2007 at 01:59:29PM +0200, Rafael J. Wysocki wrote:
>
> Actually, I thought about it for a while. The thread that is going to stop
> another one may temporarily mark itself as freezable in all cases, which
> will have no effect on it, since it's not going to cally try_to_freeze(),
On Friday, 20 April 2007 13:05, Gautham R Shenoy wrote:
> On Fri, Apr 20, 2007 at 10:54:36AM +0200, Rafael J. Wysocki wrote:
> >
> > Hmm, can't we do something like this instead:
> >
> > ---
> > kernel/kthread.c | 10 ++
> > 1 file changed, 10 insertions(+)
> >
> > Index:
On Fri, Apr 20, 2007 at 10:54:36AM +0200, Rafael J. Wysocki wrote:
>
> Hmm, can't we do something like this instead:
>
> ---
> kernel/kthread.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> Index: linux-2.6.21-rc7/kernel/kthread.c
>
On Thu, Apr 19, 2007 at 02:31:33PM -0700, Andrew Morton wrote:
> On Thu, 19 Apr 2007 17:34:19 +0530
> Gautham R Shenoy <[EMAIL PROTECTED]> wrote:
>
>
> flush_workqueue() just needs to die. I think there are (almost) no
> legitimate users of it once cancel_work_sync() is merged.
>
> > This
On Thursday, 19 April 2007 23:31, Andrew Morton wrote:
> On Thu, 19 Apr 2007 17:34:19 +0530
> Gautham R Shenoy <[EMAIL PROTECTED]> wrote:
>
> > Threads which wait for completion on a frozen thread might result in
> > causing the freezer to fail, if the waiting thread is freezeable.
> >
> >
On Thursday, 19 April 2007 23:31, Andrew Morton wrote:
On Thu, 19 Apr 2007 17:34:19 +0530
Gautham R Shenoy [EMAIL PROTECTED] wrote:
Threads which wait for completion on a frozen thread might result in
causing the freezer to fail, if the waiting thread is freezeable.
There are some
On Thu, Apr 19, 2007 at 02:31:33PM -0700, Andrew Morton wrote:
On Thu, 19 Apr 2007 17:34:19 +0530
Gautham R Shenoy [EMAIL PROTECTED] wrote:
flush_workqueue() just needs to die. I think there are (almost) no
legitimate users of it once cancel_work_sync() is merged.
This patch attempts
On Fri, Apr 20, 2007 at 10:54:36AM +0200, Rafael J. Wysocki wrote:
Hmm, can't we do something like this instead:
---
kernel/kthread.c | 10 ++
1 file changed, 10 insertions(+)
Index: linux-2.6.21-rc7/kernel/kthread.c
On Friday, 20 April 2007 13:05, Gautham R Shenoy wrote:
On Fri, Apr 20, 2007 at 10:54:36AM +0200, Rafael J. Wysocki wrote:
Hmm, can't we do something like this instead:
---
kernel/kthread.c | 10 ++
1 file changed, 10 insertions(+)
Index:
On Fri, Apr 20, 2007 at 01:59:29PM +0200, Rafael J. Wysocki wrote:
Actually, I thought about it for a while. The thread that is going to stop
another one may temporarily mark itself as freezable in all cases, which
will have no effect on it, since it's not going to cally try_to_freeze(), but
On Friday, 20 April 2007 14:26, Gautham R Shenoy wrote:
On Fri, Apr 20, 2007 at 01:59:29PM +0200, Rafael J. Wysocki wrote:
Actually, I thought about it for a while. The thread that is going to stop
another one may temporarily mark itself as freezable in all cases, which
will have no
On Fri, 20 Apr 2007 17:56:09 +0530
Gautham R Shenoy [EMAIL PROTECTED] wrote:
I mean, we already have four of them (PF_NOFREEZE, PF_FROZEN,
PF_FREEZER_SKIP, TIF_FREEZE), and you will need to introduce two more for
the freezer-based CPU hotplug, so if yet another one is needed, that will
* Andrew Morton [EMAIL PROTECTED] wrote:
I mean, we already have four of them (PF_NOFREEZE, PF_FROZEN,
PF_FREEZER_SKIP, TIF_FREEZE), and you will need to introduce two
more for the freezer-based CPU hotplug, so if yet another one is
needed, that will make up almost a separate u8
On Friday, 20 April 2007 20:31, Ingo Molnar wrote:
* Andrew Morton [EMAIL PROTECTED] wrote:
I mean, we already have four of them (PF_NOFREEZE, PF_FROZEN,
PF_FREEZER_SKIP, TIF_FREEZE), and you will need to introduce two
more for the freezer-based CPU hotplug, so if yet another
On 04/19, Gautham R Shenoy wrote:
@@ -63,12 +74,16 @@ void refrigerator(void)
recalc_sigpending(); /* We sent fake signal, clean it up */
spin_unlock_irq(current-sighand-siglock);
+ task_lock(current);
for (;;) {
On 04/20, Gautham R Shenoy wrote:
On Fri, Apr 20, 2007 at 10:54:36AM +0200, Rafael J. Wysocki wrote:
Hmm, can't we do something like this instead:
---
kernel/kthread.c | 10 ++
1 file changed, 10 insertions(+)
Index: linux-2.6.21-rc7/kernel/kthread.c
On Friday, 20 April 2007 23:20, Oleg Nesterov wrote:
On 04/20, Gautham R Shenoy wrote:
On Fri, Apr 20, 2007 at 10:54:36AM +0200, Rafael J. Wysocki wrote:
Hmm, can't we do something like this instead:
---
kernel/kthread.c | 10 ++
1 file changed, 10 insertions(+)
On Thu, 19 Apr 2007 17:34:19 +0530
Gautham R Shenoy <[EMAIL PROTECTED]> wrote:
> Threads which wait for completion on a frozen thread might result in
> causing the freezer to fail, if the waiting thread is freezeable.
>
> There are some well known cases where it's preferable to temporarily thaw
Threads which wait for completion on a frozen thread might result in
causing the freezer to fail, if the waiting thread is freezeable.
There are some well known cases where it's preferable to temporarily thaw
the frozen process, finish the wait for completion and allow both the
processes to
Threads which wait for completion on a frozen thread might result in
causing the freezer to fail, if the waiting thread is freezeable.
There are some well known cases where it's preferable to temporarily thaw
the frozen process, finish the wait for completion and allow both the
processes to
On Thu, 19 Apr 2007 17:34:19 +0530
Gautham R Shenoy [EMAIL PROTECTED] wrote:
Threads which wait for completion on a frozen thread might result in
causing the freezer to fail, if the waiting thread is freezeable.
There are some well known cases where it's preferable to temporarily thaw
the
36 matches
Mail list logo
