[RFC/PATCH 2/2] kernel: don't update load average during snapshot/shutdown

[RFC/PATCH 2/2] kernel: don't update load average during snapshot/shutdown

[Pekka J Enberg]

From: Nigel Cunningham <nigel@nigel.suspend2.net>

As explained by Nigel, Sendmail and some other programs look at the
load average and stop delivering when it gets too high.  The CPU
intensiveness of suspending to disk pushes the load average up quite
high but post-resume we shouldn't really take that into account.  Not
updating the load average therefore makes snapshot/shutdown invisible
to sendmail and so on.

Cc: Pavel Machek <pavel@ucw.cz>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Pekka Enberg <penberg@cs.helsinki.fi>
---
 include/linux/freezer.h |   13 +++++++++++++
 kernel/power/process.c  |    6 ++++++
 kernel/timer.c          |   16 +++++++++++++---
 3 files changed, 32 insertions(+), 3 deletions(-)

Index: 2.6/include/linux/freezer.h
===================================================================
--- 2.6.orig/include/linux/freezer.h	2007-04-27 16:26:12.000000000 +0300
+++ 2.6/include/linux/freezer.h	2007-04-27 16:26:14.000000000 +0300
@@ -76,6 +76,18 @@ 		return 0;
 
 extern void thaw_some_processes(int all);
 
+enum {
+	FREEZER_OFF	= 0,
+	FREEZER_ON	= 1,
+};
+
+extern int freezer_state;
+
+static inline int freezer_is_on(void)
+{
+	return freezer_state == FREEZER_ON;
+}
+
 #else
 static inline int frozen(struct task_struct *p) { return 0; }
 static inline int freezing(struct task_struct *p) { return 0; }
@@ -88,6 +100,7 @@ static inline int freeze_processes(void)
 static inline void thaw_processes(void) {}
 
 static inline int try_to_freeze(void) { return 0; }
+static inline int freezer_is_on(void) { return 0; }
 
 
 #endif
Index: 2.6/kernel/power/process.c
===================================================================
--- 2.6.orig/kernel/power/process.c	2007-04-27 16:24:45.000000000 +0300
+++ 2.6/kernel/power/process.c	2007-04-27 16:26:14.000000000 +0300
@@ -15,6 +15,8 @@
 #include <linux/syscalls.h>
 #include <linux/freezer.h>
 
+int freezer_state;
+
 /* 
  * Timeout for stopping processes
  */
@@ -183,6 +185,8 @@ int freeze_processes(void)
 	if (nr_unfrozen)
 		return nr_unfrozen;
 
+	freezer_state = FREEZER_ON;
+
 	printk("done.\n");
 	BUG_ON(in_atomic());
 	return 0;
@@ -209,6 +213,8 @@ static void thaw_tasks(int thaw_user_spa
 
 void thaw_processes(void)
 {
+	freezer_state = FREEZER_OFF;
+
 	printk("Restarting tasks ... ");
 	thaw_tasks(FREEZER_KERNEL_THREADS);
 	thaw_tasks(FREEZER_USER_SPACE);
Index: 2.6/kernel/timer.c
===================================================================
--- 2.6.orig/kernel/timer.c	2007-04-27 16:24:45.000000000 +0300
+++ 2.6/kernel/timer.c	2007-04-27 16:27:00.000000000 +0300
@@ -36,6 +36,7 @@  *                              Copyrigh
 #include <linux/delay.h>
 #include <linux/tick.h>
 #include <linux/kallsyms.h>
+#include <linux/freezer.h>
 
 #include <asm/uaccess.h>
 #include <asm/unistd.h>
@@ -1253,9 +1254,18 @@ static inline void calc_load(unsigned lo
 	if (unlikely(count < 0)) {
 		active_tasks = count_active_tasks();
 		do {
-			CALC_LOAD(avenrun[0], EXP_1, active_tasks);
-			CALC_LOAD(avenrun[1], EXP_5, active_tasks);
-			CALC_LOAD(avenrun[2], EXP_15, active_tasks);
+			/*
+			 * If we let the load average be updated while
+			 * snapshot/shutdown, it will be very high
+			 * post resume. Processes such as some MTAs
+			 * that stop work while the average is high
+			 * will be unnecessarily disrupted.
+			 */
+			if (likely(!freezer_is_on())) {
+				CALC_LOAD(avenrun[0], EXP_1, active_tasks);
+				CALC_LOAD(avenrun[1], EXP_5, active_tasks);
+				CALC_LOAD(avenrun[2], EXP_15, active_tasks);
+			}
 			count += LOAD_FREQ;
 		} while (count < 0);
 	}

Re: [RFC/PATCH 2/2] kernel: don't update load average during snapshot/shutdown

[Pavel Machek]

Hi!

> From: Nigel Cunningham <nigel@nigel.suspend2.net>
> 
> As explained by Nigel, Sendmail and some other programs look at the
> load average and stop delivering when it gets too high.  The CPU
> intensiveness of suspending to disk pushes the load average up quite
> high but post-resume we shouldn't really take that into account.  Not
> updating the load average therefore makes snapshot/shutdown invisible
> to sendmail and so on.

Is it kernel problem? We _had_ high load, and load average goes down
pretty quickly.

> @@ -1253,9 +1254,18 @@ static inline void calc_load(unsigned lo
>  	if (unlikely(count < 0)) {
>  		active_tasks = count_active_tasks();
>  		do {
> -			CALC_LOAD(avenrun[0], EXP_1, active_tasks);
> -			CALC_LOAD(avenrun[1], EXP_5, active_tasks);
> -			CALC_LOAD(avenrun[2], EXP_15, active_tasks);
> +			/*
> +			 * If we let the load average be updated while
> +			 * snapshot/shutdown, it will be very high
> +			 * post resume. Processes such as some MTAs
> +			 * that stop work while the average is high
> +			 * will be unnecessarily disrupted.
> +			 */
> +			if (likely(!freezer_is_on())) {
> +				CALC_LOAD(avenrun[0], EXP_1, active_tasks);
> +				CALC_LOAD(avenrun[1], EXP_5, active_tasks);
> +				CALC_LOAD(avenrun[2], EXP_15, active_tasks);
> +			}
>  			count += LOAD_FREQ;
>  		} while (count < 0);
>  	}

NAK. This slows down regular operation, at it is 30 lines for what
should have been one (or five).

Just place avenrun[0] = avenrun[1] = avenrun[2] = 0 at strategic place
if you feel strongly about this. Additional points for using Rafael's
"suspend done" notifier so that you don't have to modify suspend core.

								Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Re: [RFC/PATCH 2/2] kernel: don't update load average during snapshot/shutdown

[Pekka Enberg]

On 4/27/07, Pavel Machek <pavel@ucw.cz> wrote:
> Is it kernel problem? We _had_ high load, and load average goes down
> pretty quickly.

I think it is. The load average is no longer true when we resume.

On 4/27/07, Pavel Machek <pavel@ucw.cz> wrote:
> NAK. This slows down regular operation, at it is 30 lines for what
> should have been one (or five).
>
> Just place avenrun[0] = avenrun[1] = avenrun[2] = 0 at strategic place
> if you feel strongly about this. Additional points for using Rafael's
> "suspend done" notifier so that you don't have to modify suspend core.

Will do. Thanks Pavel.

Re: [RFC/PATCH 2/2] kernel: don't update load average during snapshot/shutdown

[Nigel Cunningham]

[-- Attachment #1.1: Type: text/plain, Size: 2492 bytes --]

Hi.

On Fri, 2007-04-27 at 16:52 +0200, Pavel Machek wrote:
> Hi!
> 
> > From: Nigel Cunningham <nigel@nigel.suspend2.net>
> > 
> > As explained by Nigel, Sendmail and some other programs look at the
> > load average and stop delivering when it gets too high.  The CPU
> > intensiveness of suspending to disk pushes the load average up quite
> > high but post-resume we shouldn't really take that into account.  Not
> > updating the load average therefore makes snapshot/shutdown invisible
> > to sendmail and so on.
> 
> Is it kernel problem? We _had_ high load, and load average goes down
> pretty quickly.

Don't make artificial distinctions between kernelspace and userspace.

The load average doesn't go down that quickly, and the intensiveness of
the work can make the load average _really_ high. Remember that you're
probably not seeing this because you do an atomic copy pretty quickly.
If you're compressing and writing 80% of ram to disk before the atomic
copy, what will your load average be at the end of that?

> > @@ -1253,9 +1254,18 @@ static inline void calc_load(unsigned lo
> >  	if (unlikely(count < 0)) {
> >  		active_tasks = count_active_tasks();
> >  		do {
> > -			CALC_LOAD(avenrun[0], EXP_1, active_tasks);
> > -			CALC_LOAD(avenrun[1], EXP_5, active_tasks);
> > -			CALC_LOAD(avenrun[2], EXP_15, active_tasks);
> > +			/*
> > +			 * If we let the load average be updated while
> > +			 * snapshot/shutdown, it will be very high
> > +			 * post resume. Processes such as some MTAs
> > +			 * that stop work while the average is high
> > +			 * will be unnecessarily disrupted.
> > +			 */
> > +			if (likely(!freezer_is_on())) {
> > +				CALC_LOAD(avenrun[0], EXP_1, active_tasks);
> > +				CALC_LOAD(avenrun[1], EXP_5, active_tasks);
> > +				CALC_LOAD(avenrun[2], EXP_15, active_tasks);
> > +			}
> >  			count += LOAD_FREQ;
> >  		} while (count < 0);
> >  	}
> 
> NAK. This slows down regular operation, at it is 30 lines for what
> should have been one (or five).

Count them. It is one line (an if statement) plus seven lines of
comment.

> Just place avenrun[0] = avenrun[1] = avenrun[2] = 0 at strategic place
> if you feel strongly about this. Additional points for using Rafael's
> "suspend done" notifier so that you don't have to modify suspend core.

=0 might not be right. If you did have a high load average prior to
suspending, not delivering email would be the right thing to do.

Nigel

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: [RFC/PATCH 2/2] kernel: don't update load average during snapshot/shutdown

[Pavel Machek]

Hi!

> > NAK. This slows down regular operation, at it is 30 lines for what
> > should have been one (or five).
> 
> Count them. It is one line (an if statement) plus seven lines of
> comment.

You count them. Hint... you'll need to read original patch.

> > Just place avenrun[0] = avenrun[1] = avenrun[2] = 0 at strategic place
> > if you feel strongly about this. Additional points for using Rafael's
> > "suspend done" notifier so that you don't have to modify suspend core.
> 
> =0 might not be right. If you did have a high load average prior to
> suspending, not delivering email would be the right thing to do.

Ok, so =0 is not right, but it is better than adding 30lines of junk
to the kernel.

NAK on this patch. Original behaviour is acceptable.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [RFC/PATCH 2/2] kernel: don't update load average during snapshot/shutdown

[Nigel Cunningham]

[-- Attachment #1.1: Type: text/plain, Size: 1033 bytes --]

Hi.

On Sat, 2007-04-28 at 00:12 +0200, Pavel Machek wrote:
> Hi!
> 
> > > NAK. This slows down regular operation, at it is 30 lines for what
> > > should have been one (or five).
> > 
> > Count them. It is one line (an if statement) plus seven lines of
> > comment.
> 
> You count them. Hint... you'll need to read original patch.

Ah. You're assuming this is the only use of freezer_is_on().

> > > Just place avenrun[0] = avenrun[1] = avenrun[2] = 0 at strategic place
> > > if you feel strongly about this. Additional points for using Rafael's
> > > "suspend done" notifier so that you don't have to modify suspend core.
> > 
> > =0 might not be right. If you did have a high load average prior to
> > suspending, not delivering email would be the right thing to do.
> 
> Ok, so =0 is not right, but it is better than adding 30lines of junk
> to the kernel.
> 
> NAK on this patch. Original behaviour is acceptable.

to someone who IIRC correctly recently said he doesn't even use the
code.

Nigel

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: [RFC/PATCH 2/2] kernel: don't update load average during snapshot/shutdown

[Pavel Machek]

Hi!

> > > > NAK. This slows down regular operation, at it is 30 lines for what
> > > > should have been one (or five).
> > > 
> > > Count them. It is one line (an if statement) plus seven lines of
> > > comment.
> > 
> > You count them. Hint... you'll need to read original patch.
> 
> Ah. You're assuming this is the only use of freezer_is_on().

Yes. You need quite good reason for hack like freezer_is_on(), and
this is not it.

> > > > Just place avenrun[0] = avenrun[1] = avenrun[2] = 0 at strategic place
> > > > if you feel strongly about this. Additional points for using Rafael's
> > > > "suspend done" notifier so that you don't have to modify suspend core.
> > > 
> > > =0 might not be right. If you did have a high load average prior to
> > > suspending, not delivering email would be the right thing to do.
> > 
> > Ok, so =0 is not right, but it is better than adding 30lines of junk
> > to the kernel.
> > 
> > NAK on this patch. Original behaviour is acceptable.
> 
> to someone who IIRC correctly recently said he doesn't even use the
> code.

If you want to work with me, learn how to write kernel code, learn
english, and learn how to behave.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [RFC/PATCH 2/2] kernel: don't update load average during snapshot/shutdown

[Nigel Cunningham]

[-- Attachment #1.1: Type: text/plain, Size: 2584 bytes --]

Hi.

On Sat, 2007-04-28 at 00:25 +0200, Pavel Machek wrote:
> Hi!
> 
> > > > > NAK. This slows down regular operation, at it is 30 lines for what
> > > > > should have been one (or five).
> > > > 
> > > > Count them. It is one line (an if statement) plus seven lines of
> > > > comment.
> > > 
> > > You count them. Hint... you'll need to read original patch.
> > 
> > Ah. You're assuming this is the only use of freezer_is_on().
> 
> Yes. You need quite good reason for hack like freezer_is_on(), and
> this is not it.
> 
> > > > > Just place avenrun[0] = avenrun[1] = avenrun[2] = 0 at strategic place
> > > > > if you feel strongly about this. Additional points for using Rafael's
> > > > > "suspend done" notifier so that you don't have to modify suspend core.
> > > > 
> > > > =0 might not be right. If you did have a high load average prior to
> > > > suspending, not delivering email would be the right thing to do.
> > > 
> > > Ok, so =0 is not right, but it is better than adding 30lines of junk
> > > to the kernel.
> > > 
> > > NAK on this patch. Original behaviour is acceptable.
> > 
> > to someone who IIRC correctly recently said he doesn't even use the
> > code.
> 
> If you want to work with me, learn how to write kernel code, learn
> english, and learn how to behave.

Pavel, I would love to work well with you, but I just find you arrogant
and unhelpful. I don't think it's just me. In the past, I've seen you
tell users to fix problems themselves. I've seen you dismiss real
problems (like this) as acceptable. That's not acceptable. If we want
Linux to be the best and most useful operating system out there, we have
to be willing to support things that we personally don't find useful,
and help people with problems that we personally don't care about that
much.

I haven't spent something like seven years working on hibernation
support because I find it fun or because I have nothing better to do.
I've worked on it because you're happy with a solution that just doesn't
cut the mustard for me and thousands of other people.

If I could find a way that we could work together and get those features
that others find useful and helpful in, I'd jump at it. But that just
doesn't seem to be possible.

I therefore have to ask: Please. Go away. Hand the maintainership of
hibernation over to Rafael. Work on things you do care about and where
you do want to see a fully functional implementation. But stop being a
hindrance to us making Linux hibernation support everything that it
ought to be.

Nigel

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: [RFC/PATCH 2/2] kernel: don't update load average during snapshot/shutdown

[Pavel Machek]

Hi!

> I therefore have to ask: Please. Go away. Hand the maintainership of
> hibernation over to Rafael. Work on things you do care about and where
> you do want to see a fully functional implementation. But stop being a
> hindrance to us making Linux hibernation support everything that it
> ought to be.

No, I do not think I can go away just now, not with you trying to mess
up Linux kernel in the name of Linux hibernation.

If you think you can work with Rafael, go ahead. Rafael does not seem
to have any problems working with me, and he has neccessary element
called "taste". I do not know about Pekka, yet, but at least he _listens_.

Now, please don't try to poison me-Rafael or me-Pekka communication by
angry flames each time I NAK some patch. If you do that, I'll have
to ignore you and/or blacklist you.



-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [RFC/PATCH 2/2] kernel: don't update load average during snapshot/shutdown

[Pekka Enberg]

Nigel Cunningham wrote:
> I therefore have to ask: Please. Go away. Hand the maintainership of
> hibernation over to Rafael. Work on things you do care about and where
> you do want to see a fully functional implementation. But stop being a
> hindrance to us making Linux hibernation support everything that it
> ought to be.

[snip]

Please. The load average is a problem and no the fix is not to make 
kernel/timer.c worse for everybody but to snapshot the load averages 
_before_ I/O and restore them after resume.

So can we please drop the drama? Pretty please? And sugar on the top? 
Thank you.

			Pekka

Re: [RFC/PATCH 2/2] kernel: don't update load average during snapshot/shutdown

[Rafael J. Wysocki]

On Saturday, 28 April 2007 10:26, Pekka Enberg wrote:
> Nigel Cunningham wrote:
> > I therefore have to ask: Please. Go away. Hand the maintainership of
> > hibernation over to Rafael. Work on things you do care about and where
> > you do want to see a fully functional implementation. But stop being a
> > hindrance to us making Linux hibernation support everything that it
> > ought to be.
> 
> [snip]
> 
> Please. The load average is a problem and no the fix is not to make 
> kernel/timer.c worse for everybody but to snapshot the load averages 
> _before_ I/O and restore them after resume.

I'm having an impression that this problem is suspend2-specific.  With swsusp
we can have it only if the writing of snapshot fails.

Namely, with swsusp we have the pre-snapshot value of the load average in the
image and it should be, so to speak, "normal".  Then, once we've restored the
image, this "normal" value gets recovered and everything is fine.  If the writing
of image fails, we can have a "wrong" (i.e. too high) value of the load average
afterwards, but then this is an error condition anyway.  At least, as a user, I
can expect some glitches to happen after a failing hibernation.

With suspend2, in turn, the contents of LRU pages are saved before we create
the snapshot.  They can be compressed etc. in the process, so the load average
can grow quite substantially and this "unusual" load average is then
snapshotted.  Hence, the problem appears after the restore.  I think the
solution could be to save the post-tasks-freezing load average and restore it
right before snapshotting, but that's only needed for suspend2.

Greetings,
Rafael

Re: Re: [RFC/PATCH 2/2] kernel: don't update load average during snapshot/shutdown

[Rafael J. Wysocki]

On Saturday, 28 April 2007 12:49, Rafael J. Wysocki wrote:
> On Saturday, 28 April 2007 10:26, Pekka Enberg wrote:
> > Nigel Cunningham wrote:
> > > I therefore have to ask: Please. Go away. Hand the maintainership of
> > > hibernation over to Rafael. Work on things you do care about and where
> > > you do want to see a fully functional implementation. But stop being a
> > > hindrance to us making Linux hibernation support everything that it
> > > ought to be.
> > 
> > [snip]
> > 
> > Please. The load average is a problem and no the fix is not to make 
> > kernel/timer.c worse for everybody but to snapshot the load averages 
> > _before_ I/O and restore them after resume.
> 
> I'm having an impression that this problem is suspend2-specific.  With swsusp
> we can have it only if the writing of snapshot fails.
> 
> Namely, with swsusp we have the pre-snapshot value of the load average in the
> image and it should be, so to speak, "normal".  Then, once we've restored the
> image, this "normal" value gets recovered and everything is fine.  If the writing
> of image fails, we can have a "wrong" (i.e. too high) value of the load average
> afterwards, but then this is an error condition anyway.  At least, as a user, I
> can expect some glitches to happen after a failing hibernation.
> 
> With suspend2, in turn, the contents of LRU pages are saved before we create
> the snapshot.  They can be compressed etc. in the process, so the load average
> can grow quite substantially and this "unusual" load average is then
> snapshotted.  Hence, the problem appears after the restore.  I think the
> solution could be to save the post-tasks-freezing load average and restore it
> right before snapshotting, but that's only needed for suspend2.

Well, I was wrong.  We can have this problem too with swsusp if we need to free
much memory before snapshotting the system.

Greetings,
Rafael

Re: [RFC/PATCH 2/2] kernel: don't update load average during snapshot/shutdown

[Nigel Cunningham]

[-- Attachment #1.1: Type: text/plain, Size: 1871 bytes --]

Hi.

On Sat, 2007-04-28 at 12:49 +0200, Rafael J. Wysocki wrote:
> On Saturday, 28 April 2007 10:26, Pekka Enberg wrote:
> > Nigel Cunningham wrote:
> > > I therefore have to ask: Please. Go away. Hand the maintainership of
> > > hibernation over to Rafael. Work on things you do care about and where
> > > you do want to see a fully functional implementation. But stop being a
> > > hindrance to us making Linux hibernation support everything that it
> > > ought to be.
> > 
> > [snip]
> > 
> > Please. The load average is a problem and no the fix is not to make 
> > kernel/timer.c worse for everybody but to snapshot the load averages 
> > _before_ I/O and restore them after resume.
> 
> I'm having an impression that this problem is suspend2-specific.  With swsusp
> we can have it only if the writing of snapshot fails.
> 
> Namely, with swsusp we have the pre-snapshot value of the load average in the
> image and it should be, so to speak, "normal".  Then, once we've restored the
> image, this "normal" value gets recovered and everything is fine.  If the writing
> of image fails, we can have a "wrong" (i.e. too high) value of the load average
> afterwards, but then this is an error condition anyway.  At least, as a user, I
> can expect some glitches to happen after a failing hibernation.
> 
> With suspend2, in turn, the contents of LRU pages are saved before we create
> the snapshot.  They can be compressed etc. in the process, so the load average
> can grow quite substantially and this "unusual" load average is then
> snapshotted.  Hence, the problem appears after the restore.  I think the
> solution could be to save the post-tasks-freezing load average and restore it
> right before snapshotting, but that's only needed for suspend2.

Yes, you and Pekka are both right. That would work too.

Regards,

Nigel

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: [RFC/PATCH 2/2] kernel: don't update load average during snapshot/shutdown

[Rafael J. Wysocki]

On Friday, 27 April 2007 15:29, Pekka J Enberg wrote:
> From: Nigel Cunningham <nigel@nigel.suspend2.net>
> 
> As explained by Nigel, Sendmail and some other programs look at the
> load average and stop delivering when it gets too high.  The CPU
> intensiveness of suspending to disk pushes the load average up quite
> high but post-resume we shouldn't really take that into account.  Not
> updating the load average therefore makes snapshot/shutdown invisible
> to sendmail and so on.
> 
> Cc: Pavel Machek <pavel@ucw.cz>
> Cc: Rafael J. Wysocki <rjw@sisk.pl>
> Signed-off-by: Pekka Enberg <penberg@cs.helsinki.fi>

This clashes with the recent freezer changes in -mm quite violently.

We're moving the freezer to kernel/freezer.c and we're introducing a special
field in task_struct for the freezer flags.

Please have a look at the freezer changes queued up in -mm and the freezer
patches recently sent.

Greetings,
Rafael

Re: [RFC/PATCH 2/2] kernel: don't update load average during snapshot/shutdown

[Pekka Enberg]

Rafael J. Wysocki wrote:
> Please have a look at the freezer changes queued up in -mm and the freezer
> patches recently sent.

I don't think it clashes when I do the changes suggested by Pavel.

Re: [RFC/PATCH 2/2] kernel: don't update load average during snapshot/shutdown

[Rafael J. Wysocki]

On Friday, 27 April 2007 16:59, Pekka Enberg wrote:
> Rafael J. Wysocki wrote:
> > Please have a look at the freezer changes queued up in -mm and the freezer
> > patches recently sent.
> 
> I don't think it clashes when I do the changes suggested by Pavel.

Yes, you're probably right.

Re: Re: [RFC/PATCH 2/2] kernel: don't update load average during snapshot/shutdown

[Johannes Berg]

[-- Attachment #1.1: Type: text/plain, Size: 319 bytes --]

On Fri, 2007-04-27 at 17:00 +0200, Rafael J. Wysocki wrote:

> This clashes with the recent freezer changes in -mm quite violently.

Can't somebody have a git tree for things like that? It can still be
imported into -mm, but tracking -mm just for the sake of the suspend
stuff isn't always feasible.

johannes

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Re: [RFC/PATCH 2/2] kernel: don't update load average during snapshot/shutdown

[Pavel Machek]

Hi!

> > This clashes with the recent freezer changes in -mm quite violently.
> 
> Can't somebody have a git tree for things like that? It can still be
> imported into -mm, but tracking -mm just for the sake of the suspend
> stuff isn't always feasible.

I think we should track -mm for now. git tree means Linus has to
trust you, and if he does not, you are in _big_ trouble.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Re: [RFC/PATCH 2/2] kernel: don't update load average during snapshot/shutdown

[Johannes Berg]

[-- Attachment #1.1: Type: text/plain, Size: 493 bytes --]

On Fri, 2007-04-27 at 17:05 +0200, Pavel Machek wrote:

> I think we should track -mm for now. git tree means Linus has to
> trust you, and if he does not, you are in _big_ trouble.

We could still generate patches from the actual git tree and send those
on to -mm. Bit more work though. Dunno. I try to import patches I see on
the mailing list into my own patch queue, but that seems not to be
effective all the time (never saw the freezer changes anywhere for
example)

johannes

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Re: [RFC/PATCH 2/2] kernel: don't update load average during snapshot/shutdown

[Pavel Machek]

Hi!

> > I think we should track -mm for now. git tree means Linus has to
> > trust you, and if he does not, you are in _big_ trouble.
> 
> We could still generate patches from the actual git tree and send those
> on to -mm. Bit more work though. Dunno. I try to import patches I
> > see on

git history generates "bad" patches for merging. If you merge foo,
then do two fixups, it is three patches; very nasty to review.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Re: [RFC/PATCH 2/2] kernel: don't update load average during snapshot/shutdown

[Rafael J. Wysocki]

On Friday, 27 April 2007 17:12, Johannes Berg wrote:
> On Fri, 2007-04-27 at 17:05 +0200, Pavel Machek wrote:
> 
> > I think we should track -mm for now. git tree means Linus has to
> > trust you, and if he does not, you are in _big_ trouble.
> 
> We could still generate patches from the actual git tree and send those
> on to -mm. Bit more work though. Dunno. I try to import patches I see on
> the mailing list into my own patch queue, but that seems not to be
> effective all the time (never saw the freezer changes anywhere for
> example)

The freezer patches went through the LKML.

Generally, I expect we'll have quite a lot of patches floating around in the
near future and a separate common tree would be handy, if someone has the
time to maintain it.

I can set up a quilt patch series and export it for everyone from my webserver
if that helps.

Greetings,
Rafael

Re: Re: [RFC/PATCH 2/2] kernel: don't update load average during snapshot/shutdown

[Johannes Berg]

[-- Attachment #1.1: Type: text/plain, Size: 214 bytes --]

On Fri, 2007-04-27 at 17:53 +0200, Rafael J. Wysocki wrote:

> I can set up a quilt patch series and export it for everyone from my webserver
> if that helps.

That would be useful, to me anyway.

johannes

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Re: [RFC/PATCH 2/2] kernel: don't update load average during snapshot/shutdown

[Gautham R Shenoy]

On Fri, Apr 27, 2007 at 05:00:52PM +0200, Rafael J. Wysocki wrote:
> 
> This clashes with the recent freezer changes in -mm quite violently.
>

Yes. But I anyway plan to have a system_freeze_event_mask. That can
very well serve this purpose.

> We're moving the freezer to kernel/freezer.c and we're introducing a special
> field in task_struct for the freezer flags.
> 
> Please have a look at the freezer changes queued up in -mm and the freezer
> patches recently sent.

I am not sure if the recently sent freezer patches hit lkml.
I cannot spot the address in the CC list.

> 
> Greetings,
> Rafael
> _______________________________________________
> linux-pm mailing list
> linux-pm@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/linux-pm

-- 
Gautham R Shenoy
Linux Technology Center
IBM India.
"Freedom comes with a price tag of responsibility, which is still a bargain,
because Freedom is priceless!"

Re: Re: [RFC/PATCH 2/2] kernel: don't update load average during snapshot/shutdown

[Rafael J. Wysocki]

On Friday, 27 April 2007 17:16, Gautham R Shenoy wrote:
> On Fri, Apr 27, 2007 at 05:00:52PM +0200, Rafael J. Wysocki wrote:
> > 
> > This clashes with the recent freezer changes in -mm quite violently.
> >
> 
> Yes. But I anyway plan to have a system_freeze_event_mask. That can
> very well serve this purpose.
> 
> > We're moving the freezer to kernel/freezer.c and we're introducing a special
> > field in task_struct for the freezer flags.
> > 
> > Please have a look at the freezer changes queued up in -mm and the freezer
> > patches recently sent.
> 
> I am not sure if the recently sent freezer patches hit lkml.
> I cannot spot the address in the CC list.

Ohs...t,  I did it again.  Sorry for the confusion.

Sending in a while.  I'll add Pekka to the CC list this time. :-)

Greetings,
Rafael