headers
Brown, Len | 6 Apr 2006 00:03
Picon
Favicon
Gravatar

HZ vs battery life

I measured idle battery life at 250HZ, which is what my SL10.1-beta8
laptop has as the default.

I compiled the distro kernel with HZ=1000 and battery life got worse --
no surpose.

But then I built with HZ=100 and it was the same results as HZ=1000,
when I expected it to be better than HZ=250.

clues?
-Len

ps. yes, I'm running at init5.  I'll repeat at init1.
-
To unsubscribe from this list: send the line "unsubscribe linux-laptop" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Brown, Len | 8 Apr 2006 08:42
Picon
Favicon
Gravatar

kernel vs user power management

Timo, Holger,
Andi pointed me to your FOSDEM Linux Power Management presentation:

http://en.opensuse.org/FOSDEM2006

http://files.opensuse.org/opensuse/en/b/b5/One_step_opendesign.pdf

And I'm glad to see you working on Linux Power Management.

But I'm a little concerned that user-space and the kernel are
a little out of sync on a few things.

I'm happy to see that the userspace p-state governor
is no longer enabled by default on SuSE systems.
While it was passable on servers with steady-state
workloads, it was very bad for laptops where the
machine spends a lot of time idle, but has short
bursts of processing need which userspace could
not detect.  These laptops would spend virtually
all their time in Pn when using the userspace governor.

The next step is to delete the userspace governor
as a valid governor selection entirely.  If somebody
really wants manual control, they can still set the
limits within which "ondemand" will stay.

I'm happy to see that clock throttling is not enabled by
default in recent SuSE release, at least on my laptop
which supports P-states.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Holger Macht | 8 Apr 2006 19:18
Picon

Re: kernel vs user power management

On Sat 08. Apr - 02:42:12, Brown, Len wrote:
> Timo, Holger,
> Andi pointed me to your FOSDEM Linux Power Management presentation:
> 
> http://en.opensuse.org/FOSDEM2006
> 
> http://files.opensuse.org/opensuse/en/b/b5/One_step_opendesign.pdf
> 
> And I'm glad to see you working on Linux Power Management.
> 
> But I'm a little concerned that user-space and the kernel are
> a little out of sync on a few things.
> 
> I'm happy to see that the userspace p-state governor
> is no longer enabled by default on SuSE systems.
> While it was passable on servers with steady-state
> workloads, it was very bad for laptops where the
> machine spends a lot of time idle, but has short
> bursts of processing need which userspace could
> not detect.  These laptops would spend virtually
> all their time in Pn when using the userspace governor.

To be honest, this observation suprises me a little bit. We did some
measurements with userspace agains ondemand governor some time ago and did
not notice any big differences in the results between them. Well, these
tests are about 1 1/2 years ago, though, and there went some changes into
the kernel until now ;-)

Nevertheless, we adjust the sampling rate in any case and currently set it
to 333 milliseconds (that's configurable). We noticed if we use the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brown, Len | 9 Apr 2006 05:06
Picon
Favicon
Gravatar

RE: kernel vs user power management

>On Sat 08. Apr - 02:42:12, Brown, Len wrote:
>> Timo, Holger,
>> Andi pointed me to your FOSDEM Linux Power Management presentation:
>> 
>> http://en.opensuse.org/FOSDEM2006
>> 
>> http://files.opensuse.org/opensuse/en/b/b5/One_step_opendesign.pdf
>> 
>> And I'm glad to see you working on Linux Power Management.
>> 
>> But I'm a little concerned that user-space and the kernel are
>> a little out of sync on a few things.
>> 
>> I'm happy to see that the userspace p-state governor
>> is no longer enabled by default on SuSE systems.
>> While it was passable on servers with steady-state
>> workloads, it was very bad for laptops where the
>> machine spends a lot of time idle, but has short
>> bursts of processing need which userspace could
>> not detect.  These laptops would spend virtually
>> all their time in Pn when using the userspace governor.
>
>To be honest, this observation suprises me a little bit. We did some
>measurements with userspace agains ondemand governor some time 
>ago and did not notice any big differences in the results between them.
>Well, these tests are about 1 1/2 years ago, though, and there went some 
>changes into the kernel until now ;-)

Yes, measurements show that ondemand as improved
considerably since its initial implementation.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andi Kleen | 9 Apr 2006 08:07
Picon

Re: kernel vs user power management

On Sunday 09 April 2006 05:06, Brown, Len wrote:

> >Furthermore, we had some problems on multiprocessor systems in the past
> >(about 1/2 year ago) with the ondemand governor. After some time the
> >system was running (even some hours or even days) the machine locked up
> >hard.  Thus, we set the userspace governor by default on those systems
> >where we never experienced such problems. At the moment I did 
> >only get one similar report where the root cause is not clear.
> 
> It is important that this failure be root caused and this
> doubt be put behind us.  Got a bug URL?

IIRC that was a powernow-k8 problem - should be fixed now.

> I don't know if the amd-specific drivers would work or not.
> Last I heard their latency was too high, but maybe they've
> fixed that.

I don't think so.

> I think you'll need to keep the userspace backup scheme for systems
> which have switching latency too high to load and run ondemand.

That would be pretty much all AMD systems at least.
But it's ugly - it would be better if ondemand worked on those too.
Anyways not your problem I guess, Len.

> >If so, I fully agree with you. But I do not set a specific 
> >policy in the powersave code explicitely for that feature.
> >If the policy information
(Continue reading)

Permalink | Reply | 0 comments |
headers
Holger Macht | 10 Apr 2006 10:35
Picon

Re: kernel vs user power management

On Sat 08. Apr - 23:06:54, Brown, Len wrote:
> >On Sat 08. Apr - 02:42:12, Brown, Len wrote:
> >> Timo, Holger,
> >> Andi pointed me to your FOSDEM Linux Power Management presentation:
> >> 
> >> http://en.opensuse.org/FOSDEM2006
> >> 
> >> http://files.opensuse.org/opensuse/en/b/b5/One_step_opendesign.pdf
> >> 
> >> And I'm glad to see you working on Linux Power Management.
> >> 
> >> But I'm a little concerned that user-space and the kernel are
> >> a little out of sync on a few things.
> >> 
> >> I'm happy to see that the userspace p-state governor
> >> is no longer enabled by default on SuSE systems.
> >> While it was passable on servers with steady-state
> >> workloads, it was very bad for laptops where the
> >> machine spends a lot of time idle, but has short
> >> bursts of processing need which userspace could
> >> not detect.  These laptops would spend virtually
> >> all their time in Pn when using the userspace governor.
> >
> >To be honest, this observation suprises me a little bit. We did some
> >measurements with userspace agains ondemand governor some time 
> >ago and did not notice any big differences in the results between them.
> >Well, these tests are about 1 1/2 years ago, though, and there went some 
> >changes into the kernel until now ;-)
> 
> Yes, measurements show that ondemand as improved
(Continue reading)

Permalink | Reply | 0 comments |
headers
chuck gelm | 10 Apr 2006 12:48

Re:

Matthias Güntert wrote:

>help
>
>  
>
Find a telephone and dial 911.

HTH, Chuck

-
To unsubscribe from this list: send the line "unsubscribe linux-laptop" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Khushil Dep | 10 Apr 2006 16:52
Picon

RE:

Or 999 if you're in the UK or even 112 from a mobile but under no circustances should you e-mail a bunch of linux folks....

-----Original Message-----
From: linux-laptop-owner <at> vger.kernel.org [mailto:linux-laptop-owner <at> vger.kernel.org] On Behalf
Of chuck gelm
Sent: 10 April 2006 11:48
To: Matthias Güntert
Cc: linux-laptop <at> vger.kernel.org
Subject: Re: 

Matthias Güntert wrote:

>help
>
>  
>
Find a telephone and dial 911.

HTH, Chuck

-
To unsubscribe from this list: send the line "unsubscribe linux-laptop" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line "unsubscribe linux-laptop" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andreas Mohr | 17 Apr 2006 00:05
Picon

[PATCH] -mm: i386 apm.c optimization

Hello all,

- avoid expensive modulo (integer division) which happened
  since APM_MAX_EVENTS is 20 (non-power-of-2)
- kill compiler warnings by initializing two variables
- add __read_mostly to some important static variables that are read often
  (by idle loop etc.)
- constify several structures

Patch tested on 2.6.16-ck5, rediffed against 2.6.17-rc1-mm2.

Signed-off-by: Andreas Mohr <andi <at> lisas.de>

diff -urN linux-2.6.17-rc1-mm2.orig/arch/i386/kernel/apm.c linux-2.6.17-rc1-mm2/arch/i386/kernel/apm.c
--- linux-2.6.17-rc1-mm2.orig/arch/i386/kernel/apm.c	2006-04-03 05:22:10.000000000 +0200
+++ linux-2.6.17-rc1-mm2/arch/i386/kernel/apm.c	2006-04-16 23:49:00.000000000 +0200
 <at>  <at>  -374,14 +374,14  <at>  <at> 
 	unsigned short	segment;
 }				apm_bios_entry;
 static int			clock_slowed;
-static int			idle_threshold = DEFAULT_IDLE_THRESHOLD;
-static int			idle_period = DEFAULT_IDLE_PERIOD;
+static int			idle_threshold __read_mostly = DEFAULT_IDLE_THRESHOLD;
+static int			idle_period __read_mostly = DEFAULT_IDLE_PERIOD;
 static int			set_pm_idle;
 static int			suspends_pending;
 static int			standbys_pending;
 static int			ignore_sys_suspend;
 static int			ignore_normal_resume;
-static int			bounce_interval = DEFAULT_BOUNCE_INTERVAL;
(Continue reading)

Permalink | Reply | 0 comments |

Gmane