headers
Tobias Weingartner | 1 Jul 2010 03:59
Favicon

Re: better cpu throttling

On Wednesday, June 30, Darrin Chandler wrote:
> 
> What you're saying is true, but that's not the only use case. Streaming
> media may not benefit from 100% cpu but may not be able to work properly
> at 0%. The same goes for other common tasks as well. Running at 30% or
> 50% will indeed save power for those cases where running at 100% won't
> make what you're doing finish faster and running at 0% won't work.

You're assuming that the switch is so slow that running at a constant
average factor (of whatever) is better than simply switching to "high"
mode when there are things to do (not in idle loop), and going back to
"low" mode when there is nothing left to do (in idle loop/etc).  The
system could litteraly be switching high/low several thousand times a
second...

Try the diff, see if it works for you.

--Toby.
Permalink | Reply | 1 comment |
headers
Jordan Hargrave | 1 Jul 2010 08:00
Picon

ACPI PCI Mapping diff

This diff will attempt to match up ACPI PCI devices with their BDF.
This will replace code currently used in acpiprt, but need to test this on 
many machines to make sure the bus numbers match.

Code will panic if bus numbers do not match, please report dmesg if you 
see a panic, along with pcidump -vv output on booted kernel.

Index: acpi.c
===================================================================
RCS file: /cvs/src/sys/dev/acpi/acpi.c,v
retrieving revision 1.168
diff -u -p -u -p -b -r1.168 acpi.c
--- acpi.c	1 Jul 2010 06:29:32 -0000	1.168
+++ acpi.c	1 Jul 2010 06:56:15 -0000
 <at>  <at>  -1,4 +1,4  <at>  <at> 
-/* $OpenBSD: acpi.c,v 1.168 2010/07/01 06:29:32 jordan Exp $ */
+/* $OpenBSD: acpi.c,v 1.167 2010/07/01 01:39:39 jordan Exp $ */
  /*
   * Copyright (c) 2005 Thorsten Lockert <tholo <at> sigmasoft.com>
   * Copyright (c) 2005 Jordan Hargrave <jordan <at> openbsd.org>
 <at>  <at>  -18,6 +18,7  <at>  <at> 

  #include <sys/param.h>
  #include <sys/systm.h>
+#include <sys/buf.h>
  #include <sys/device.h>
  #include <sys/malloc.h>
  #include <sys/fcntl.h>
 <at>  <at>  -41,6 +42,10  <at>  <at> 
  #include <dev/acpi/dsdt.h>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jordan Hargrave | 1 Jul 2010 10:37
Picon

ACPI PCI mapping revert diff

So found the problem; on the R210 the AML code CHANGES the _HID 
for the PCI Root Bus depending 
on the _OSI OS running.. UGH

I'd had code in dsdt.c for ages that converted the _HID integer value to 
its PNP-string equivalent at create time.   However with the dynamic _HID 
changing code in the AML, the store tried to convert an integer value to a 
string, eg. storing integer HID 0x12345 became "12345" instead 
of PNP0A03.

I took out the default _HID conversion code in dsdt.c and reverted back to 
the original code, this does work on the R210 but would like to test on 
other systems as well.

The old acpiprt code worked because it searched for ANY _HID value.. the
new code explicitly looks for PNP0A03 or PNP0A08.

 <at> tech, please test this diff and report any issues with panic

Index: acpi.c
===================================================================
RCS file: /cvs/src/sys/dev/acpi/acpi.c,v
retrieving revision 1.168
diff -u -p -u -p -r1.168 acpi.c
--- acpi.c	1 Jul 2010 06:29:32 -0000	1.168
+++ acpi.c	1 Jul 2010 09:02:54 -0000
 <at>  <at>  -1,4 +1,4  <at>  <at> 
-/* $OpenBSD: acpi.c,v 1.168 2010/07/01 06:29:32 jordan Exp $ */
+/* $OpenBSD: acpi.c,v 1.167 2010/07/01 01:39:39 jordan Exp $ */
  /*
(Continue reading)

Permalink | Reply | 3 comments |
headers
Martin Toft | 1 Jul 2010 13:20
Picon
Gravatar

Re: better cpu throttling

On Wed, Jun 30, 2010 at 02:32:26PM -0400, Ted Unangst wrote:
> I like this one better.  Slow down the poll interval just a little so
> it's not so hysterical, but also go straight to 100.  If you need CPU,
> you need CPU.  It still backs down slowly, but that's just to prevent
> getting caught in slow mode again. 

Me too - my laptop is (as expected) more responsive than with the other
diff.  Playing a video, however, results in

going up 100
going down 90
going down 80
going up 100
going down 90
going down 80
going down 70
going up 100
going down 90
going down 80
going up 100
going down 90
going up 100
going down 90
going down 80
going down 70
going down 60
...

which is not exactly bad (the video is played just fine), but I wonder
whether it is as efficient battery-wise as converging to e.g. 60-70 over
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stuart Henderson | 1 Jul 2010 14:27
Favicon
Gravatar

Re: ACPI PCI mapping revert diff

On 2010/07/01 03:37, Jordan Hargrave wrote:
> So found the problem; on the R210 the AML code CHANGES the _HID for
> the PCI Root Bus depending on the _OSI OS running.. UGH
> 
> I'd had code in dsdt.c for ages that converted the _HID integer value
> to its PNP-string equivalent at create time.   However with the
> dynamic _HID changing code in the AML, the store tried to convert an
> integer value to a string, eg. storing integer HID 0x12345 became
> "12345" instead of PNP0A03.
> 
> I took out the default _HID conversion code in dsdt.c and reverted
> back to the original code, this does work on the R210 but would like
> to test on other systems as well.
> 
> The old acpiprt code worked because it searched for ANY _HID value.. the
> new code explicitly looks for PNP0A03 or PNP0A08.
> 
>  <at> tech, please test this diff and report any issues with panic

What code is this diff meant to apply to? There are many conflicts when
attempting to apply it to -current (acpi.c 1.168, acpiprt.c 1.38, etc).
Permalink | Reply | 2 comments |
headers
Darrin Chandler | 1 Jul 2010 16:19
Favicon
Gravatar

Re: better cpu throttling

On Wed, Jun 30, 2010 at 07:59:00PM -0600, Tobias Weingartner wrote:
> On Wednesday, June 30, Darrin Chandler wrote:
> > 
> > What you're saying is true, but that's not the only use case. Streaming
> > media may not benefit from 100% cpu but may not be able to work properly
> > at 0%. The same goes for other common tasks as well. Running at 30% or
> > 50% will indeed save power for those cases where running at 100% won't
> > make what you're doing finish faster and running at 0% won't work.
> 
> You're assuming that the switch is so slow that running at a constant
> average factor (of whatever) is better than simply switching to "high"
> mode when there are things to do (not in idle loop), and going back to
> "low" mode when there is nothing left to do (in idle loop/etc).  The
> system could litteraly be switching high/low several thousand times a
> second...
> 
> Try the diff, see if it works for you.

It's been pointed out to me off list. Of course I should have tested
first and then came with issues as I found them.

--

-- 
Darrin Chandler            |  Phoenix BSD User Group  |  MetaBUG
dwchandler <at> stilyagin.com   |  http://phxbug.org/      |  http://metabug.org/
http://www.stilyagin.com/  |  Daemons in the Desert   |  Global BUG Federation
Permalink | Reply | 0 comments |
headers
jordan hargrave | 1 Jul 2010 17:27
Picon

Re: ACPI PCI mapping revert diff

Hmm.. this should work off -current (the reverted stuff).
rm *.c *.h in dev/acpi
cvs xxx -q up -PAd
patch < revert.diff

Essentially, it's a backout of the backout, plus the _HID change..
The hid diff alone (makes R210 work on pre-revert) is:
Index: dsdt.c
===================================================================
RCS file: /cvs/src/sys/dev/acpi/dsdt.c,v
retrieving revision 1.163
diff -u -p -u -p -b -r1.163 dsdt.c
--- dsdt.c      1 Jul 2010 01:39:39 -0000       1.163
+++ dsdt.c      1 Jul 2010 15:25:48 -0000
 <at>  <at>  -3745,12 +3745,7  <at>  <at>  aml_xparse(struct aml_scope *scope, int
               /* Name: Nt */
               rv = opargs[0];
               aml_freevalue(rv);
-               if (!strcmp(rv->node->name, "_HID") && opargs[1]->type
== AML_OBJTYPE_INTEGER) {
-                       /* Shortcut for _HID: autoconvert to string */
-                       _aml_setvalue(rv, AML_OBJTYPE_STRING, -1,
aml_eisaid(opargs[1]->v_integer));
-               } else {
                       aml_copyvalue(rv, opargs[1]);
-               }
               break;
       case AMLOP_ALIAS:
               /* Alias: nN */
(Continue reading)

Permalink | Reply | 1 comment |

Gmane