Hi!
> Rafael,
> On Sat, Feb 17, 2007 at 12:24:45PM +0100, Rafael J. Wysocki wrote:
> >
> > Pavel, do you think we can remove the PF_NOFREEZE from bluetooth, BTW?
>
> The create_workqueue by default marks the worker_threads to be
> non_freezable. For cpu hotplug, all workqueues can be frozen
>
Rafael,
On Sat, Feb 17, 2007 at 12:24:45PM +0100, Rafael J. Wysocki wrote:
>
> Pavel, do you think we can remove the PF_NOFREEZE from bluetooth, BTW?
The create_workqueue by default marks the worker_threads to be
non_freezable. For cpu hotplug, all workqueues can be frozen
except the "kthread"
Rafael,
On Sat, Feb 17, 2007 at 12:24:45PM +0100, Rafael J. Wysocki wrote:
Pavel, do you think we can remove the PF_NOFREEZE from bluetooth, BTW?
The create_workqueue by default marks the worker_threads to be
non_freezable. For cpu hotplug, all workqueues can be frozen
except the kthread
Hi!
Rafael,
On Sat, Feb 17, 2007 at 12:24:45PM +0100, Rafael J. Wysocki wrote:
Pavel, do you think we can remove the PF_NOFREEZE from bluetooth, BTW?
The create_workqueue by default marks the worker_threads to be
non_freezable. For cpu hotplug, all workqueues can be frozen
except the
On Sunday, 18 February 2007 17:11, Oleg Nesterov wrote:
> On 02/18, Rafael J. Wysocki wrote:
> >
> > > On Sunday, 18 February 2007 12:31, Oleg Nesterov wrote:
> > > >
> > > > A very vague idea: what if parent will do
> > > >
> > > > current->flags |=
> > > >
On 02/18, Rafael J. Wysocki wrote:
>
> > On Sunday, 18 February 2007 12:31, Oleg Nesterov wrote:
> > >
> > > A very vague idea: what if parent will do
> > >
> > > current->flags |= PF_PLEASE_CONSIDER_ME_AS_FROZEN_BUT_SET_TIF_FREEZE
> > > wait_for_completion();
> > > try_to_freeze();
> > >
On Sunday, 18 February 2007 13:14, Rafael J. Wysocki wrote:
> On Sunday, 18 February 2007 12:31, Oleg Nesterov wrote:
> > On 02/18, Rafael J. Wysocki wrote:
> > >
> > > On Sunday, 18 February 2007 00:47, Oleg Nesterov wrote:
> > > >
> > > > However, this means that sys_vfork() makes impossible to
On 02/18, Rafael J. Wysocki wrote:
>
> On Sunday, 18 February 2007 12:32, Oleg Nesterov wrote:
> > On 02/18, Rafael J. Wysocki wrote:
> > >
> > > On Sunday, 18 February 2007 00:42, Oleg Nesterov wrote:
> > > > On 02/17, Rafael J. Wysocki wrote:
> > > > >
> > > > > On Saturday, 17 February 2007
Hi!
> > > So I think tonight I'll start adding try_to_freeze() to the kernel
> > > threads that
> > > set PF_NOFREEZE.
> >
> > cool! While you are at it, let me try to enhance the freezer api's
> > to incorporate the PFE_* flags.
>
> Here's a patch that adds try_to_freeze() to all kernel
On Sunday, 18 February 2007 12:32, Oleg Nesterov wrote:
> On 02/18, Rafael J. Wysocki wrote:
> >
> > On Sunday, 18 February 2007 00:42, Oleg Nesterov wrote:
> > > On 02/17, Rafael J. Wysocki wrote:
> > > >
> > > > On Saturday, 17 February 2007 22:34, Oleg Nesterov wrote:
> > > > >
> > > > >
On Sunday, 18 February 2007 12:31, Oleg Nesterov wrote:
> On 02/18, Rafael J. Wysocki wrote:
> >
> > On Sunday, 18 February 2007 00:47, Oleg Nesterov wrote:
> > >
> > > However, this means that sys_vfork() makes impossible to freeze processes
> > > until child exits/execs. Not good.
> >
> > Yes,
On 02/18, Rafael J. Wysocki wrote:
>
> On Sunday, 18 February 2007 00:42, Oleg Nesterov wrote:
> > On 02/17, Rafael J. Wysocki wrote:
> > >
> > > On Saturday, 17 February 2007 22:34, Oleg Nesterov wrote:
> > > >
> > > > static inline int is_user_space(struct task_struct *p)
> > > >
On 02/18, Rafael J. Wysocki wrote:
>
> On Sunday, 18 February 2007 00:47, Oleg Nesterov wrote:
> >
> > However, this means that sys_vfork() makes impossible to freeze processes
> > until child exits/execs. Not good.
>
> Yes, but this also is the current behavior.
Yes, yes, I see.
I forgot to
On Sunday, 18 February 2007 00:42, Oleg Nesterov wrote:
> On 02/17, Rafael J. Wysocki wrote:
> >
> > On Saturday, 17 February 2007 22:34, Oleg Nesterov wrote:
> > >
> > > static inline int is_user_space(struct task_struct *p)
> > > {
> > > return p->mm && !(p->flags &
On Sunday, 18 February 2007 00:47, Oleg Nesterov wrote:
> On 02/18, Oleg Nesterov wrote:
> >
> > On 02/17, Rafael J. Wysocki wrote:
> > >
> > > Alternatively, we can move the check into refrigerator(), like this:
> > >
> > > --- linux-2.6.20-git13.orig/kernel/power/process.c
> > > +++
On Sunday, 18 February 2007 00:42, Oleg Nesterov wrote:
On 02/17, Rafael J. Wysocki wrote:
On Saturday, 17 February 2007 22:34, Oleg Nesterov wrote:
static inline int is_user_space(struct task_struct *p)
{
return p-mm !(p-flags PF_BORROWED_MM);
}
This
On Sunday, 18 February 2007 00:47, Oleg Nesterov wrote:
On 02/18, Oleg Nesterov wrote:
On 02/17, Rafael J. Wysocki wrote:
Alternatively, we can move the check into refrigerator(), like this:
--- linux-2.6.20-git13.orig/kernel/power/process.c
+++
On 02/18, Rafael J. Wysocki wrote:
On Sunday, 18 February 2007 00:47, Oleg Nesterov wrote:
However, this means that sys_vfork() makes impossible to freeze processes
until child exits/execs. Not good.
Yes, but this also is the current behavior.
Yes, yes, I see.
I forgot to say that we
On 02/18, Rafael J. Wysocki wrote:
On Sunday, 18 February 2007 00:42, Oleg Nesterov wrote:
On 02/17, Rafael J. Wysocki wrote:
On Saturday, 17 February 2007 22:34, Oleg Nesterov wrote:
static inline int is_user_space(struct task_struct *p)
{
On Sunday, 18 February 2007 12:31, Oleg Nesterov wrote:
On 02/18, Rafael J. Wysocki wrote:
On Sunday, 18 February 2007 00:47, Oleg Nesterov wrote:
However, this means that sys_vfork() makes impossible to freeze processes
until child exits/execs. Not good.
Yes, but this also is
On Sunday, 18 February 2007 12:32, Oleg Nesterov wrote:
On 02/18, Rafael J. Wysocki wrote:
On Sunday, 18 February 2007 00:42, Oleg Nesterov wrote:
On 02/17, Rafael J. Wysocki wrote:
On Saturday, 17 February 2007 22:34, Oleg Nesterov wrote:
static inline int
Hi!
So I think tonight I'll start adding try_to_freeze() to the kernel
threads that
set PF_NOFREEZE.
cool! While you are at it, let me try to enhance the freezer api's
to incorporate the PFE_* flags.
Here's a patch that adds try_to_freeze() to all kernel threads that didn't
On 02/18, Rafael J. Wysocki wrote:
On Sunday, 18 February 2007 12:32, Oleg Nesterov wrote:
On 02/18, Rafael J. Wysocki wrote:
On Sunday, 18 February 2007 00:42, Oleg Nesterov wrote:
On 02/17, Rafael J. Wysocki wrote:
On Saturday, 17 February 2007 22:34, Oleg Nesterov wrote:
On Sunday, 18 February 2007 13:14, Rafael J. Wysocki wrote:
On Sunday, 18 February 2007 12:31, Oleg Nesterov wrote:
On 02/18, Rafael J. Wysocki wrote:
On Sunday, 18 February 2007 00:47, Oleg Nesterov wrote:
However, this means that sys_vfork() makes impossible to freeze
On 02/18, Rafael J. Wysocki wrote:
On Sunday, 18 February 2007 12:31, Oleg Nesterov wrote:
A very vague idea: what if parent will do
current-flags |= PF_PLEASE_CONSIDER_ME_AS_FROZEN_BUT_SET_TIF_FREEZE
wait_for_completion(vfork);
try_to_freeze();
?
Hm, what
On Sunday, 18 February 2007 17:11, Oleg Nesterov wrote:
On 02/18, Rafael J. Wysocki wrote:
On Sunday, 18 February 2007 12:31, Oleg Nesterov wrote:
A very vague idea: what if parent will do
current-flags |=
PF_PLEASE_CONSIDER_ME_AS_FROZEN_BUT_SET_TIF_FREEZE
On 02/18, Oleg Nesterov wrote:
>
> On 02/17, Rafael J. Wysocki wrote:
> >
> > Alternatively, we can move the check into refrigerator(), like this:
> >
> > --- linux-2.6.20-git13.orig/kernel/power/process.c
> > +++ linux-2.6.20-git13/kernel/power/process.c
> > @@ -39,6 +39,11 @@ void
On 02/17, Rafael J. Wysocki wrote:
>
> On Saturday, 17 February 2007 22:34, Oleg Nesterov wrote:
> >
> > static inline int is_user_space(struct task_struct *p)
> > {
> > return p->mm && !(p->flags & PF_BORROWED_MM);
> > }
> >
> > This doesn't look right. First, an exiting
On Saturday, 17 February 2007 22:34, Oleg Nesterov wrote:
> Rafael, I am trying to understand try_to_freeze_tasks(), and I have a
> couple of questions.
>
> static inline int is_user_space(struct task_struct *p)
> {
> return p->mm && !(p->flags & PF_BORROWED_MM);
>
Rafael, I am trying to understand try_to_freeze_tasks(), and I have a
couple of questions.
static inline int is_user_space(struct task_struct *p)
{
return p->mm && !(p->flags & PF_BORROWED_MM);
}
This doesn't look right. First, an exiting task has ->mm ==
On Thursday, 15 February 2007 15:25, Gautham R Shenoy wrote:
> On Thu, Feb 15, 2007 at 02:31:08PM +0100, Rafael J. Wysocki wrote:
> >
> > So I think tonight I'll start adding try_to_freeze() to the kernel threads
> > that
> > set PF_NOFREEZE.
>
> cool! While you are at it, let me try to enhance
On Thursday, 15 February 2007 15:25, Gautham R Shenoy wrote:
On Thu, Feb 15, 2007 at 02:31:08PM +0100, Rafael J. Wysocki wrote:
So I think tonight I'll start adding try_to_freeze() to the kernel threads
that
set PF_NOFREEZE.
cool! While you are at it, let me try to enhance the
Rafael, I am trying to understand try_to_freeze_tasks(), and I have a
couple of questions.
static inline int is_user_space(struct task_struct *p)
{
return p-mm !(p-flags PF_BORROWED_MM);
}
This doesn't look right. First, an exiting task has -mm == NULL
On Saturday, 17 February 2007 22:34, Oleg Nesterov wrote:
Rafael, I am trying to understand try_to_freeze_tasks(), and I have a
couple of questions.
static inline int is_user_space(struct task_struct *p)
{
return p-mm !(p-flags PF_BORROWED_MM);
}
This
On 02/17, Rafael J. Wysocki wrote:
On Saturday, 17 February 2007 22:34, Oleg Nesterov wrote:
static inline int is_user_space(struct task_struct *p)
{
return p-mm !(p-flags PF_BORROWED_MM);
}
This doesn't look right. First, an exiting task has -mm == NULL
On 02/18, Oleg Nesterov wrote:
On 02/17, Rafael J. Wysocki wrote:
Alternatively, we can move the check into refrigerator(), like this:
--- linux-2.6.20-git13.orig/kernel/power/process.c
+++ linux-2.6.20-git13/kernel/power/process.c
@@ -39,6 +39,11 @@ void refrigerator(void)
/*
On Thu, Feb 15, 2007 at 02:31:08PM +0100, Rafael J. Wysocki wrote:
>
> So I think tonight I'll start adding try_to_freeze() to the kernel threads
> that
> set PF_NOFREEZE.
cool! While you are at it, let me try to enhance the freezer api's
to incorporate the PFE_* flags.
> >
> > That would
On Thursday, 15 February 2007 13:20, Gautham R Shenoy wrote:
> On Thu, Feb 15, 2007 at 09:09:51AM +0100, Rafael J. Wysocki wrote:
> > >
> > > Why should we make sure that PF_NOFREEZE tasks are also frozen for
> > > cpu hotplug? Instead, we can create an infrastructure which allows
> > > threads
On Thu, Feb 15, 2007 at 09:09:51AM +0100, Rafael J. Wysocki wrote:
> >
> > Why should we make sure that PF_NOFREEZE tasks are also frozen for
> > cpu hotplug? Instead, we can create an infrastructure which allows threads
> > to
> > specify for the scenarios they would want to be excempted from
On Thursday, 15 February 2007 07:34, Gautham R Shenoy wrote:
> On Wed, Feb 14, 2007 at 10:43:35PM +0100, Rafael J. Wysocki wrote:
> > Hi,
> >
> > On Wednesday, 14 February 2007 15:40, Gautham R Shenoy wrote:
> > > Hello Everybody,
> > >
> > > This is an experiment towards process_freezer based
On Thursday, 15 February 2007 07:34, Gautham R Shenoy wrote:
On Wed, Feb 14, 2007 at 10:43:35PM +0100, Rafael J. Wysocki wrote:
Hi,
On Wednesday, 14 February 2007 15:40, Gautham R Shenoy wrote:
Hello Everybody,
This is an experiment towards process_freezer based implementation
On Thu, Feb 15, 2007 at 09:09:51AM +0100, Rafael J. Wysocki wrote:
Why should we make sure that PF_NOFREEZE tasks are also frozen for
cpu hotplug? Instead, we can create an infrastructure which allows threads
to
specify for the scenarios they would want to be excempted from freeze.
On Thursday, 15 February 2007 13:20, Gautham R Shenoy wrote:
On Thu, Feb 15, 2007 at 09:09:51AM +0100, Rafael J. Wysocki wrote:
Why should we make sure that PF_NOFREEZE tasks are also frozen for
cpu hotplug? Instead, we can create an infrastructure which allows
threads to
specify
On Thu, Feb 15, 2007 at 02:31:08PM +0100, Rafael J. Wysocki wrote:
So I think tonight I'll start adding try_to_freeze() to the kernel threads
that
set PF_NOFREEZE.
cool! While you are at it, let me try to enhance the freezer api's
to incorporate the PFE_* flags.
That would still mean
On Wed, Feb 14, 2007 at 10:43:35PM +0100, Rafael J. Wysocki wrote:
> Hi,
>
> On Wednesday, 14 February 2007 15:40, Gautham R Shenoy wrote:
> > Hello Everybody,
> >
> > This is an experiment towards process_freezer based implementation
> > of cpu-hotplug. This is mainly based on ideas of Andrew
Hi,
On Wednesday, 14 February 2007 15:40, Gautham R Shenoy wrote:
> Hello Everybody,
>
> This is an experiment towards process_freezer based implementation
> of cpu-hotplug. This is mainly based on ideas of Andrew Morton,
> Ingo Molnar and Paul Mckenney featured in the discussion
>
Hello Everybody,
This is an experiment towards process_freezer based implementation
of cpu-hotplug. This is mainly based on ideas of Andrew Morton,
Ingo Molnar and Paul Mckenney featured in the discussion
http://lkml.org/lkml/2007/1/31/323.
This is an absolute bare-minimal implementation to
Hello Everybody,
This is an experiment towards process_freezer based implementation
of cpu-hotplug. This is mainly based on ideas of Andrew Morton,
Ingo Molnar and Paul Mckenney featured in the discussion
http://lkml.org/lkml/2007/1/31/323.
This is an absolute bare-minimal implementation to
Hi,
On Wednesday, 14 February 2007 15:40, Gautham R Shenoy wrote:
Hello Everybody,
This is an experiment towards process_freezer based implementation
of cpu-hotplug. This is mainly based on ideas of Andrew Morton,
Ingo Molnar and Paul Mckenney featured in the discussion
On Wed, Feb 14, 2007 at 10:43:35PM +0100, Rafael J. Wysocki wrote:
Hi,
On Wednesday, 14 February 2007 15:40, Gautham R Shenoy wrote:
Hello Everybody,
This is an experiment towards process_freezer based implementation
of cpu-hotplug. This is mainly based on ideas of Andrew Morton,
50 matches
Mail list logo
