reading battery status and CPU time

reading battery status and CPU time

[Jan Rychter]

FYI: reading battery status still consumes lots of CPU time. Unless it's
supposed to be that way?

time cat /proc/acpi/battery/BAT0/state produces:

0.000u 0.040s 0:00.12 33.3%     0+0k 0+0io 108pf+0w
0.000u 0.040s 0:00.13 30.7%     0+0k 0+0io 108pf+0w
0.000u 0.030s 0:00.12 25.0%     0+0k 0+0io 108pf+0w
0.000u 0.030s 0:00.14 21.4%     0+0k 0+0io 108pf+0w
0.000u 0.050s 0:00.14 35.7%     0+0k 0+0io 108pf+0w
0.000u 0.030s 0:00.14 21.4%     0+0k 0+0io 108pf+0w

... which causes applications like wmacpi to consume tens of seconds of
CPU time after a while. Not really a price I'd be willing to pay for
knowing the battery status.

This is on 2.4.21-pre6 with acpi-20030328. Sharp Mebius PC-MT1-H3.

--J.


-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/

Re: reading battery status and CPU time

[Markus Gaugusch]

On Apr 4, Jan Rychter <jan-JAsPCFd0eodBDgjK7y7TUQ@public.gmane.org> wrote:
> FYI: reading battery status still consumes lots of CPU time. Unless it's
> supposed to be that way?
> This is on 2.4.21-pre6 with acpi-20030328. Sharp Mebius PC-MT1-H3.
I have the same on a Sony Vaio FX405 (0.11 sec for one "cat state").
I just disassembled and recompiled my DSDT and put some debug output
there.
Very interesting: _BIF gets called twice!
It would still mean 0.05 secs for one query, but it would at least help a
little bit.

Maybe someone can also tell me, why there are two _BIF methods in my dsdt
and only one is called. Could it be for the second battery slot? I just
pulled the battery out of the first one and the machine crashed ... maybe
my dsdt is a bit broken.
I had to remove several Store(Local0, Local0) (NOOP's?????) to make it
compile. There were no other warnings except missing return code of _WAK
(but I don't/can't use ACPI suspend).

btw: Does anybody know how I could print out 1/100 sec accurate timestamps
via syslog/dmesg?

thanks
Markus

-- 
__________________    /"\
Markus Gaugusch       \ /    ASCII Ribbon Campaign
markus-z+rTbpWsRgbk7+2FdBfRIA@public.gmane.org     X     Against HTML Mail
                      / \


-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: reading battery status and CPU time

[Herbert Nachtnebel]

Hi Markus!

> Ok, but how should I do this while AML code is being executed?

There exists the possibility to write debug messages to the console directly
from AML code. Patch the code which handles this to also write out the time stamp.

> Or do you mean in the function that prints the debug output (just came to
> my mind ...).

Yes, exactly - see above.

> Nevertheless, I don't know how to achive that (I know C/C++ but I haven't
> done much inside the kernel and don't know the function names, etc.)
> Could you give me a hint? Thanks.

Access to the time stamp counter is available via include/asm-i386/timex.h.
Look into it.

Ciau, Herbert.

PS: BTW, find and grep is your friend.


-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger
for complex code. Debugging C/C++ programs can leave you feeling lost and
disoriented. TotalView can help you find your way. Available on major UNIX
and Linux platforms. Try it free. www.etnus.com

Re: reading battery status and CPU time

[Markus Gaugusch]

I found something out about battery info being read twice:
(this is battery.c, acpi_battery_get_info())

---snip---
/* Extract Package Data */

   status = acpi_extract_package(package, &format, &data);  <-----
   if (status != AE_BUFFER_OVERFLOW) {
      ACPI_DEBUG_PRINT((ACPI_DB_ERROR, "Error extracting _BIF\n"));
      result = -ENODEV;
      goto end;
   }

   data.pointer = kmalloc(data.length, GFP_KERNEL);
   if (!data.pointer) {
      result = -ENOMEM;
      goto end;
   }
   memset(data.pointer, 0, data.length);

   status = acpi_extract_package(package, &format, &data);  <-----
   if (ACPI_FAILURE(status)) {
      ACPI_DEBUG_PRINT((ACPI_DB_ERROR, "Error extracting _BIF\n"));
      kfree(data.pointer);
      result = -ENODEV;
      goto end;
   }
---snip---


Why is acpi_extract_package called twice with different error handling?
The ASL code is definitely called twice (I've put debug statements in
there).
Same with battery state (_BST).

Markus


-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: reading battery status and CPU time

[Markus Gaugusch]

I found out something else: the acpi_battery_get_info method is called
twice when doing cat /proc/acpi/battery/BAT1/info !
The duplicate calling must come from somewhere above.
I couldn't find out where it gets called, can anybody help me?
Even grep -r acpi_battery_get_info /usr/src/linux/* didn't help?!

thanks
Markus
-- 
__________________    /"\
Markus Gaugusch       \ /    ASCII Ribbon Campaign
markus-z+rTbpWsRgbk7+2FdBfRIA@public.gmane.org     X     Against HTML Mail
                      / \


-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: reading battery status and CPU time

[Matthew Wilcox]

On Thu, Apr 10, 2003 at 11:20:30PM +0200, Markus Gaugusch wrote:
> I found something out about battery info being read twice:
> (this is battery.c, acpi_battery_get_info())
> 
> Why is acpi_extract_package called twice with different error handling?
> The ASL code is definitely called twice (I've put debug statements in
> there).

Memory management.  The first time, it's called to find out how much
memory it'll need; then we allocate some memory, then we call it again.
There's an API to have the ACPICA allocate memory for you now, but I
think it still calls the AML twice.

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk


-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: reading battery status and CPU time

[Randy.Dunlap]

On Thu, 10 Apr 2003 22:31:28 +0100 Matthew Wilcox <willy-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org> wrote:

| On Thu, Apr 10, 2003 at 11:20:30PM +0200, Markus Gaugusch wrote:
| > I found something out about battery info being read twice:
| > (this is battery.c, acpi_battery_get_info())
| > 
| > Why is acpi_extract_package called twice with different error handling?
| > The ASL code is definitely called twice (I've put debug statements in
| > there).
| 
| Memory management.  The first time, it's called to find out how much
| memory it'll need; then we allocate some memory, then we call it again.
| There's an API to have the ACPICA allocate memory for you now, but I
| think it still calls the AML twice.

Willy, is this the proc-fs phenomenon?
which will go away if this code is converted to use seq_file...

--
~Randy   ['tangent' is not a verb...unless you believe that
          "in English any noun can be verbed."]


-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

RE: reading battery status and CPU time

[Grover, Andrew]

> From: Matthew Wilcox [mailto:willy-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org]
> > Why is acpi_extract_package called twice with different error
> > handling? The ASL code is definitely called twice (I've put debug 
> > statements in there).
> 
> Memory management.  The first time, it's called to find out
> how much memory it'll need; then we allocate some memory, 
> then we call it again. There's an API to have the ACPICA 
> allocate memory for you now, but I think it still calls the AML twice.

We changed that function's acpi_evaluate_object call (the function that
does the control method) to use the interface in which the core
allocates memory.

However, this acpi_extract_package is a helper function (utils.c I
believe) that still does the overflow thing. Hasn't been a big issue
since this function doesn't do much, but it probably should be changed.

Another question is if the /proc interface is being called more than
once per cat, that might be causing multiple control method invocations,
too.

Regards -- Andy



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

RE: reading battery status and CPU time

[Markus Gaugusch]

On Apr 11, Grover, Andrew <andrew.grover-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:
> Another question is if the /proc interface is being called more than
> once per cat, that might be causing multiple control method invocations,
> too.
I'm pretty sure that this is the case. I've added some debug output which
seems to prove this for me.

Markus
-- 
__________________    /"\
Markus Gaugusch       \ /    ASCII Ribbon Campaign
markus-z+rTbpWsRgbk7+2FdBfRIA@public.gmane.org     X     Against HTML Mail
                      / \


-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

RE: reading battery status and CPU time

[Markus Gaugusch]

On Apr 11, Grover, Andrew <andrew.grover-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:
> Another question is if the /proc interface is being called more than
> once per cat, that might be causing multiple control method invocations,
> too.
Did you have time to look into this issue? It really seems to be the case,
at least according to my debug output that I added to the code.

thanks!
Markus
-- 
__________________    /"\
Markus Gaugusch       \ /    ASCII Ribbon Campaign
markus-z+rTbpWsRgbk7+2FdBfRIA@public.gmane.org     X     Against HTML Mail
                      / \


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf