On Sunday, 4 February 2007 14:50, Pavel Machek wrote:
> Hi!
>
> > > > This is needed so that the _resume_ works, when it's handled from the
> > > > user land
> > > > by our resume tool. Currently, the resume code calls
> > > > freeze_processes() too.
> > >
> > > I do not understand...
Hi!
> > > This is needed so that the _resume_ works, when it's handled from the
> > > user land
> > > by our resume tool. Currently, the resume code calls
> > > freeze_processes() too.
> >
> > I do not understand... freeze_processes() always leaves curent process
> > running... why is it
Hi,
On Sunday, 4 February 2007 13:53, Pavel Machek wrote:
> Hi!
>
> > > > > o init/do_mounts_initrd.c line 57 handle_initrd().
> > > > > This looks to be short term anyway, so OK to leave.
> > > > > But does kernel_execve() clear PF_NOFREEZE?
> > > > >
> > > > > But it
Hi!
> > > > o init/do_mounts_initrd.c line 57 handle_initrd().
> > > > This looks to be short term anyway, so OK to leave.
> > > > But does kernel_execve() clear PF_NOFREEZE?
> > > >
> > > > But it should be OK to freeze the init process when doing CPU
> > > >
On Sunday, 4 February 2007 05:39, Paul E. McKenney wrote:
> On Sat, Feb 03, 2007 at 01:17:45AM +0100, Pavel Machek wrote:
> > Hi!
> >
> > > > Part of what I need to look at. ;-)
> > >
> > > OK. This just might be feasible. That said, there is a lot of code
> > > containing PF_NOFREEZE that I
On Sunday, 4 February 2007 05:39, Paul E. McKenney wrote:
On Sat, Feb 03, 2007 at 01:17:45AM +0100, Pavel Machek wrote:
Hi!
Part of what I need to look at. ;-)
OK. This just might be feasible. That said, there is a lot of code
containing PF_NOFREEZE that I am not familiar
Hi!
o init/do_mounts_initrd.c line 57 handle_initrd().
This looks to be short term anyway, so OK to leave.
But does kernel_execve() clear PF_NOFREEZE?
But it should be OK to freeze the init process when doing CPU
hotplug ops, right?
Hi,
On Sunday, 4 February 2007 13:53, Pavel Machek wrote:
Hi!
o init/do_mounts_initrd.c line 57 handle_initrd().
This looks to be short term anyway, so OK to leave.
But does kernel_execve() clear PF_NOFREEZE?
But it should be OK to freeze the
Hi!
This is needed so that the _resume_ works, when it's handled from the
user land
by our resume tool. Currently, the resume code calls
freeze_processes() too.
I do not understand... freeze_processes() always leaves curent process
running... why is it needed?
IIRC, the
On Sunday, 4 February 2007 14:50, Pavel Machek wrote:
Hi!
This is needed so that the _resume_ works, when it's handled from the
user land
by our resume tool. Currently, the resume code calls
freeze_processes() too.
I do not understand... freeze_processes() always leaves
On Sat, Feb 03, 2007 at 01:17:45AM +0100, Pavel Machek wrote:
> Hi!
>
> > > Part of what I need to look at. ;-)
> >
> > OK. This just might be feasible. That said, there is a lot of code
> > containing PF_NOFREEZE that I am not familiar with. That said, here
> > are my thoughts -- this is in
On Sat, Feb 03, 2007 at 11:27:24PM +0100, Rafael J. Wysocki wrote:
> On Saturday, 3 February 2007 01:01, Pavel Machek wrote:
> > Hi!
> >
> > > > > > static int _cpu_down(unsigned int cpu)
> > > > > > {
> > > > > > int err;
> > > > > > struct task_struct *p;
> > > >
On Saturday, 3 February 2007 01:01, Pavel Machek wrote:
> Hi!
>
> > > > > static int _cpu_down(unsigned int cpu)
> > > > > {
> > > > > int err;
> > > > > struct task_struct *p;
> > > > > cpumask_t old_allowed, tmp;
> > > > >
> > > > >
Hi!
> > Part of what I need to look at. ;-)
>
> OK. This just might be feasible. That said, there is a lot of code
> containing PF_NOFREEZE that I am not familiar with. That said, here
> are my thoughts -- this is in addition to the changes to freeze_processes()
> and thaw_processes() called
Hi!
> > > > static int _cpu_down(unsigned int cpu)
> > > > {
> > > > int err;
> > > > struct task_struct *p;
> > > > cpumask_t old_allowed, tmp;
> > > >
> > > > if (num_online_cpus() == 1)
> > > >
Hi!
static int _cpu_down(unsigned int cpu)
{
int err;
struct task_struct *p;
cpumask_t old_allowed, tmp;
if (num_online_cpus() == 1)
return -EBUSY;
Hi!
Part of what I need to look at. ;-)
OK. This just might be feasible. That said, there is a lot of code
containing PF_NOFREEZE that I am not familiar with. That said, here
are my thoughts -- this is in addition to the changes to freeze_processes()
and thaw_processes() called out
On Saturday, 3 February 2007 01:01, Pavel Machek wrote:
Hi!
static int _cpu_down(unsigned int cpu)
{
int err;
struct task_struct *p;
cpumask_t old_allowed, tmp;
if (num_online_cpus() == 1)
On Sat, Feb 03, 2007 at 11:27:24PM +0100, Rafael J. Wysocki wrote:
On Saturday, 3 February 2007 01:01, Pavel Machek wrote:
Hi!
static int _cpu_down(unsigned int cpu)
{
int err;
struct task_struct *p;
cpumask_t
On Sat, Feb 03, 2007 at 01:17:45AM +0100, Pavel Machek wrote:
Hi!
Part of what I need to look at. ;-)
OK. This just might be feasible. That said, there is a lot of code
containing PF_NOFREEZE that I am not familiar with. That said, here
are my thoughts -- this is in addition to
On Tue, Jan 30, 2007 at 11:49:40AM -0800, Paul E. McKenney wrote:
> On Tue, Jan 30, 2007 at 10:27:18AM -0800, Andrew Morton wrote:
> > On Tue, 30 Jan 2007 17:44:47 +0100
> > "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
> >
> > > > I need to look at all uses of PF_NOFREEZE -- as I understand the
On Tue, Jan 30, 2007 at 11:49:40AM -0800, Paul E. McKenney wrote:
On Tue, Jan 30, 2007 at 10:27:18AM -0800, Andrew Morton wrote:
On Tue, 30 Jan 2007 17:44:47 +0100
Rafael J. Wysocki [EMAIL PROTECTED] wrote:
I need to look at all uses of PF_NOFREEZE -- as I understand the
code,
On Tue, Jan 30, 2007 at 10:27:18AM -0800, Andrew Morton wrote:
> On Tue, 30 Jan 2007 17:44:47 +0100
> "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
>
> > > I need to look at all uses of PF_NOFREEZE -- as I understand the
> > > code, processes marked PF_NOFREEZE will continue running, potentially
On Tue, 30 Jan 2007 17:44:47 +0100
"Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
> > I need to look at all uses of PF_NOFREEZE -- as I understand the
> > code, processes marked PF_NOFREEZE will continue running, potentially
> > interfering with the hotplug operation. :-(
> >
> > I will pass my
On Tue, Jan 30, 2007 at 07:32:27PM +0530, Gautham R Shenoy wrote:
> On Mon, Jan 29, 2007 at 06:45:49PM -0800, Paul E. McKenney wrote:
> >
> > static int _cpu_down(unsigned int cpu)
> > {
> > int err;
> > struct task_struct *p;
> > cpumask_t old_allowed,
On Tuesday, 30 January 2007 17:02, Paul E. McKenney wrote:
> On Tue, Jan 30, 2007 at 08:33:40AM +0100, Ingo Molnar wrote:
> >
> > * Paul E. McKenney <[EMAIL PROTECTED]> wrote:
> >
> > > > in fact (new) kprobes uses the freezer, and it's far more
> > > > performance sensitive than the handling
On Tue, Jan 30, 2007 at 08:33:40AM +0100, Ingo Molnar wrote:
>
> * Paul E. McKenney <[EMAIL PROTECTED]> wrote:
>
> > > in fact (new) kprobes uses the freezer, and it's far more
> > > performance sensitive than the handling of CPU hotplug events.
> >
> > Outside of realtime workloads, I agree
On Mon, Jan 29, 2007 at 06:45:49PM -0800, Paul E. McKenney wrote:
>
> static int _cpu_down(unsigned int cpu)
> {
> int err;
> struct task_struct *p;
> cpumask_t old_allowed, tmp;
>
> if (num_online_cpus() == 1)
>
On Mon, Jan 29, 2007 at 06:45:49PM -0800, Paul E. McKenney wrote:
static int _cpu_down(unsigned int cpu)
{
int err;
struct task_struct *p;
cpumask_t old_allowed, tmp;
if (num_online_cpus() == 1)
On Tue, Jan 30, 2007 at 08:33:40AM +0100, Ingo Molnar wrote:
* Paul E. McKenney [EMAIL PROTECTED] wrote:
in fact (new) kprobes uses the freezer, and it's far more
performance sensitive than the handling of CPU hotplug events.
Outside of realtime workloads, I agree that performance
On Tuesday, 30 January 2007 17:02, Paul E. McKenney wrote:
On Tue, Jan 30, 2007 at 08:33:40AM +0100, Ingo Molnar wrote:
* Paul E. McKenney [EMAIL PROTECTED] wrote:
in fact (new) kprobes uses the freezer, and it's far more
performance sensitive than the handling of CPU hotplug
On Tue, Jan 30, 2007 at 07:32:27PM +0530, Gautham R Shenoy wrote:
On Mon, Jan 29, 2007 at 06:45:49PM -0800, Paul E. McKenney wrote:
static int _cpu_down(unsigned int cpu)
{
int err;
struct task_struct *p;
cpumask_t old_allowed, tmp;
On Tue, 30 Jan 2007 17:44:47 +0100
Rafael J. Wysocki [EMAIL PROTECTED] wrote:
I need to look at all uses of PF_NOFREEZE -- as I understand the
code, processes marked PF_NOFREEZE will continue running, potentially
interfering with the hotplug operation. :-(
I will pass my findings on
On Tue, Jan 30, 2007 at 10:27:18AM -0800, Andrew Morton wrote:
On Tue, 30 Jan 2007 17:44:47 +0100
Rafael J. Wysocki [EMAIL PROTECTED] wrote:
I need to look at all uses of PF_NOFREEZE -- as I understand the
code, processes marked PF_NOFREEZE will continue running, potentially
* Paul E. McKenney <[EMAIL PROTECTED]> wrote:
> > in fact (new) kprobes uses the freezer, and it's far more
> > performance sensitive than the handling of CPU hotplug events.
>
> Outside of realtime workloads, I agree that performance should not be
> a problem. And I don't know of any reason
On Mon, Jan 29, 2007 at 08:12:41PM +0100, Ingo Molnar wrote:
>
> * Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > > The idea being to essentially suspend the system to RAM, remove the
> > > CPU and then unsuspend it? Seems like quite high overhead -- or am
> > > I misunderstanding the
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> > The idea being to essentially suspend the system to RAM, remove the
> > CPU and then unsuspend it? Seems like quite high overhead -- or am
> > I misunderstanding the proposal?
>
> The process freezer basically wakes up all threads in the machine
* Andrew Morton [EMAIL PROTECTED] wrote:
The idea being to essentially suspend the system to RAM, remove the
CPU and then unsuspend it? Seems like quite high overhead -- or am
I misunderstanding the proposal?
The process freezer basically wakes up all threads in the machine and
On Mon, Jan 29, 2007 at 08:12:41PM +0100, Ingo Molnar wrote:
* Andrew Morton [EMAIL PROTECTED] wrote:
The idea being to essentially suspend the system to RAM, remove the
CPU and then unsuspend it? Seems like quite high overhead -- or am
I misunderstanding the proposal?
The
* Paul E. McKenney [EMAIL PROTECTED] wrote:
in fact (new) kprobes uses the freezer, and it's far more
performance sensitive than the handling of CPU hotplug events.
Outside of realtime workloads, I agree that performance should not be
a problem. And I don't know of any reason why
On Sun, Jan 28, 2007 at 03:30:05PM -0800, Andrew Morton wrote:
> On Sun, 28 Jan 2007 14:47:56 -0800
> "Paul E. McKenney" <[EMAIL PROTECTED]> wrote:
>
> > > If we use the process freezer, these bugs all get automatically fixed,
> > > and we get to remove the existing locking, and we don't need to
On Sun, 28 Jan 2007 14:47:56 -0800
"Paul E. McKenney" <[EMAIL PROTECTED]> wrote:
> > If we use the process freezer, these bugs all get automatically fixed,
> > and we get to remove the existing locking, and we don't need to think
> > about it any more.
>
> The idea being to essentially suspend
On Fri, Jan 26, 2007 at 01:29:49PM -0800, Andrew Morton wrote:
> On Sat, 27 Jan 2007 02:14:06 +0530
> Dipankar Sarma <[EMAIL PROTECTED]> wrote:
>
> > On Fri, Jan 26, 2007 at 12:17:39PM -0800, Andrew Morton wrote:
> > > On Sat, 27 Jan 2007 01:16:22 +0530
> > > Dipankar Sarma <[EMAIL PROTECTED]>
On Fri, Jan 26, 2007 at 01:29:49PM -0800, Andrew Morton wrote:
On Sat, 27 Jan 2007 02:14:06 +0530
Dipankar Sarma [EMAIL PROTECTED] wrote:
On Fri, Jan 26, 2007 at 12:17:39PM -0800, Andrew Morton wrote:
On Sat, 27 Jan 2007 01:16:22 +0530
Dipankar Sarma [EMAIL PROTECTED] wrote:
The
On Sun, 28 Jan 2007 14:47:56 -0800
Paul E. McKenney [EMAIL PROTECTED] wrote:
If we use the process freezer, these bugs all get automatically fixed,
and we get to remove the existing locking, and we don't need to think
about it any more.
The idea being to essentially suspend the system to
On Sun, Jan 28, 2007 at 03:30:05PM -0800, Andrew Morton wrote:
On Sun, 28 Jan 2007 14:47:56 -0800
Paul E. McKenney [EMAIL PROTECTED] wrote:
If we use the process freezer, these bugs all get automatically fixed,
and we get to remove the existing locking, and we don't need to think
On Sat, 27 Jan 2007 02:14:06 +0530
Dipankar Sarma <[EMAIL PROTECTED]> wrote:
> On Fri, Jan 26, 2007 at 12:17:39PM -0800, Andrew Morton wrote:
> > On Sat, 27 Jan 2007 01:16:22 +0530
> > Dipankar Sarma <[EMAIL PROTECTED]> wrote:
> > > > The plan is, I hope, to rip it all out and do
On Fri, Jan 26, 2007 at 12:17:39PM -0800, Andrew Morton wrote:
> On Sat, 27 Jan 2007 01:16:22 +0530
> Dipankar Sarma <[EMAIL PROTECTED]> wrote:
> > > The plan is, I hope, to rip it all out and do freeze_processes() on the
> > > hotplug side, so nobody else needs to worry about cpu hotplug any
On Sat, 27 Jan 2007 01:16:22 +0530
Dipankar Sarma <[EMAIL PROTECTED]> wrote:
> > The plan is, I hope, to rip it all out and do freeze_processes() on the
> > hotplug side, so nobody else needs to worry about cpu hotplug any more.
> > But at present everyone seems to be in hiding.
>
> This would
On Sat, 27 Jan 2007 00:41:13 +0530
Dipankar Sarma <[EMAIL PROTECTED]> wrote:
> On Thu, Jan 25, 2007 at 02:36:45AM +0530, Dipankar Sarma wrote:
> > On Wed, Jan 24, 2007 at 08:15:59AM -0800, Paul E. McKenney wrote:
> >
> > It should be relatively easy. Setting the offlined cpu's flags
> > to
On Fri, Jan 26, 2007 at 11:28:37AM -0800, Andrew Morton wrote:
> On Sat, 27 Jan 2007 00:41:13 +0530
> Dipankar Sarma <[EMAIL PROTECTED]> wrote:
>
> > Is this a good example to
> > show why per-subsystem locks might be unmaintainable ?
>
> Maybe. It might also be a good example of confused
On Thu, Jan 25, 2007 at 02:36:45AM +0530, Dipankar Sarma wrote:
> On Wed, Jan 24, 2007 at 08:15:59AM -0800, Paul E. McKenney wrote:
>
> It should be relatively easy. Setting the offlined cpu's flags
> to neutral state should do the trick in most cases.
> I will send out the patches tomorrow after
On Thu, Jan 25, 2007 at 02:36:45AM +0530, Dipankar Sarma wrote:
On Wed, Jan 24, 2007 at 08:15:59AM -0800, Paul E. McKenney wrote:
It should be relatively easy. Setting the offlined cpu's flags
to neutral state should do the trick in most cases.
I will send out the patches tomorrow after
On Fri, Jan 26, 2007 at 11:28:37AM -0800, Andrew Morton wrote:
On Sat, 27 Jan 2007 00:41:13 +0530
Dipankar Sarma [EMAIL PROTECTED] wrote:
Is this a good example to
show why per-subsystem locks might be unmaintainable ?
Maybe. It might also be a good example of confused design.
Not
On Sat, 27 Jan 2007 00:41:13 +0530
Dipankar Sarma [EMAIL PROTECTED] wrote:
On Thu, Jan 25, 2007 at 02:36:45AM +0530, Dipankar Sarma wrote:
On Wed, Jan 24, 2007 at 08:15:59AM -0800, Paul E. McKenney wrote:
It should be relatively easy. Setting the offlined cpu's flags
to neutral state
On Sat, 27 Jan 2007 01:16:22 +0530
Dipankar Sarma [EMAIL PROTECTED] wrote:
The plan is, I hope, to rip it all out and do freeze_processes() on the
hotplug side, so nobody else needs to worry about cpu hotplug any more.
But at present everyone seems to be in hiding.
This would be ideal.
On Fri, Jan 26, 2007 at 12:17:39PM -0800, Andrew Morton wrote:
On Sat, 27 Jan 2007 01:16:22 +0530
Dipankar Sarma [EMAIL PROTECTED] wrote:
The plan is, I hope, to rip it all out and do freeze_processes() on the
hotplug side, so nobody else needs to worry about cpu hotplug any more.
But
On Sat, 27 Jan 2007 02:14:06 +0530
Dipankar Sarma [EMAIL PROTECTED] wrote:
On Fri, Jan 26, 2007 at 12:17:39PM -0800, Andrew Morton wrote:
On Sat, 27 Jan 2007 01:16:22 +0530
Dipankar Sarma [EMAIL PROTECTED] wrote:
The plan is, I hope, to rip it all out and do freeze_processes() on the
58 matches
Mail list logo
