performance problems?

performance problems?

[Thomas List]

Hi all,

I'm working on a small battery applet for my laptop that reads out the 
battery status. As I have up to now no better idea I'm pulling the 
battery status (/proc/acpi/battery/...) every few seconds (anyone an 
idea of how to do this better?). Now a battery applet should consume as 
few CPU cycles as possible to not use up the battery itself. So I'm 
trying to monitor how much computing time my applet is using. For the 
moment I'm doing this using top (I know this is not perfect for that 
task ...). Now to the problem:

After the laptop is running for some time the CPU% value in top is 
getting higher and higher. It starts with around 0.3% in the beginning, 
after one hour it reaches 1,5% and I had it up to 3% and more after a 
longer time. I am quite sure this is not my applet - I can stop the 
program and restart it and still get the higher values. I tried to watch 
a video in this state and while my program was running I had short stops 
in the video play back that match the 2 seconds interval of pulling the 
battery status. Without my program running the stops disappeared.
Using a file system copy of /proc/acpi my program does not show at all 
on the top list.

I am using acpi 20021111 on a 2.4.20-rc1 kernel. The laptop is a Targa 
visionary 1600 from actebis (mobile athlon on a Via ProSavage KN133 
"TwisterK" board). I think I did not have such problems with an older 
acpi version (20021022 ???) - I will check this out).

Now could this be a problem with the acpi implementation or is this the 
result of a wrong usage of acpi?


Btw. - is there any documentation on the /proc/acpi directories besides 
Dominik Brodowski's documentation for /proc/acpi/processor?

Thanks for any help,

   Thomas




-------------------------------------------------------
This sf.net email is sponsored by: To learn the basics of securing 
your web site with SSL, click here to get a FREE TRIAL of a Thawte 
Server Certificate: http://www.gothawte.com/rd524.html

Re: performance problems?

[Loic Jaquemet]

i'am using 2.4.19 + around october patch ( I'll check that this evening )
on sony vaio fx502

I've experienced the same problem with my personnal adaptation of wmacpi ..

when I fetch the /proc/acpi/<batteriesxxx>/state|info files, I get a 1-2
second freeze| lag ..

It might be linked with acpi as at this precise instant I can see some
kacpid processes briefly created ..

Maybe the battery-status fetching lag is a hardware limitation ?

I'm not sure, but i think i didn't have this problem on pre-september
patches ..

++

Thomas List wrote:

> Hi all,
>
> I'm working on a small battery applet for my laptop that reads out the
> battery status. As I have up to now no better idea I'm pulling the
> battery status (/proc/acpi/battery/...) every few seconds (anyone an
> idea of how to do this better?). Now a battery applet should consume as
> few CPU cycles as possible to not use up the battery itself. So I'm
> trying to monitor how much computing time my applet is using. For the
> moment I'm doing this using top (I know this is not perfect for that
> task ...). Now to the problem:
>
> After the laptop is running for some time the CPU% value in top is
> getting higher and higher. It starts with around 0.3% in the beginning,
> after one hour it reaches 1,5% and I had it up to 3% and more after a
> longer time. I am quite sure this is not my applet - I can stop the
> program and restart it and still get the higher values. I tried to watch
> a video in this state and while my program was running I had short stops
> in the video play back that match the 2 seconds interval of pulling the
> battery status. Without my program running the stops disappeared.
> Using a file system copy of /proc/acpi my program does not show at all
> on the top list.
>
> I am using acpi 20021111 on a 2.4.20-rc1 kernel. The laptop is a Targa
> visionary 1600 from actebis (mobile athlon on a Via ProSavage KN133
> "TwisterK" board). I think I did not have such problems with an older
> acpi version (20021022 ???) - I will check this out).
>
> Now could this be a problem with the acpi implementation or is this the
> result of a wrong usage of acpi?
>
> Btw. - is there any documentation on the /proc/acpi directories besides
> Dominik Brodowski's documentation for /proc/acpi/processor?
>
> Thanks for any help,
>
>    Thomas
>
> -------------------------------------------------------
> This sf.net email is sponsored by: To learn the basics of securing
> your web site with SSL, click here to get a FREE TRIAL of a Thawte
> Server Certificate: http://www.gothawte.com/rd524.html
> _______________________________________________
> Acpi-devel mailing list
> Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/acpi-devel

--
+----------------------------------------------+
|Jaquemet Loic                                 |
|Intern in WesternGeco, Schlumberger in Gatwick|
|Phone: 44-(0)1293-55-6876                     |
|Eleve ingenieur en informatique FIIFO, ORSAY  |
+----------------------------------------------+
http://sourceforge.net/projects/ffss/
#wirelessfr @ irc.freenode.net





-------------------------------------------------------
This sf.net email is sponsored by: To learn the basics of securing 
your web site with SSL, click here to get a FREE TRIAL of a Thawte 
Server Certificate: http://www.gothawte.com/rd524.html

Re: performance problems?

[Markus Gaugusch]

On Nov 19, Loic Jaquemet <ljaquemet-BNG0eM9rGRi0IRkH3yUr9EW4647UYGdYQQ4Iyu8u01E@public.gmane.org> wrote:
> i'am using 2.4.19 + around october patch ( I'll check that this evening )
> on sony vaio fx502
> [...]
> when I fetch the /proc/acpi/<batteriesxxx>/state|info files, I get a 1-2
> second freeze| lag ..
> [...]
> I'm not sure, but i think i didn't have this problem on pre-september
> patches ..
No, it has been present before. I have an FX405 and can't use any battery
monitor applet that reads the info file. Even a 'cat
/proc/acpi/battery/BAT1/info' causes a noticable peak in my cpu monitor
(kernel time). At least, it doesn't freeze keyboard anymore, thanks to the
ACPI people!

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



-------------------------------------------------------
This sf.net email is sponsored by: To learn the basics of securing 
your web site with SSL, click here to get a FREE TRIAL of a Thawte 
Server Certificate: http://www.gothawte.com/rd524.html

Re: performance problems?

[James D Strandboge]

On Tue, 2002-11-19 at 09:54, Markus Gaugusch wrote:
> On Nov 19, Loic Jaquemet <ljaquemet-BNG0eM9rGRi0IRkH3yUr9EW4647UYGdYQQ4Iyu8u01E@public.gmane.org> wrote:
> > i'am using 2.4.19 + around october patch ( I'll check that this evening )
> > on sony vaio fx502
> > [...]
> > when I fetch the /proc/acpi/<batteriesxxx>/state|info files, I get a 1-2
> > second freeze| lag ..
> > [...]
> > I'm not sure, but i think i didn't have this problem on pre-september
> > patches ..
> No, it has been present before. I have an FX405 and can't use any battery
> monitor applet that reads the info file. Even a 'cat
> /proc/acpi/battery/BAT1/info' causes a noticable peak in my cpu monitor
> (kernel time). At least, it doesn't freeze keyboard anymore, thanks to the
> ACPI people!
> 

You want to poll /proc/acpi/battery/BAT1/state or whatever is correct
for your battery.  Polling info requires interrupts with the BIOS I
think, and state is there for a quick poll.  At least on my machine this
is the case.  

Perhaps someone would want to clarify the difference and why info causes
a hang and state does not.

Jamie Strandboge


-- 
Email:        jstrand1-aYIB8uWIUb2Vn7q6wjsIow@public.gmane.org
GPG/PGP ID:   26384A3A
Fingerprint:  D9FF DF4A 2D46 A353 A289  E8F5 AA75 DCBE 2638 4A3A

Visit Perinton Nursery School at:
http://perintonnurseryschool.org/



-------------------------------------------------------
This sf.net email is sponsored by: To learn the basics of securing 
your web site with SSL, click here to get a FREE TRIAL of a Thawte 
Server Certificate: http://www.gothawte.com/rd524.html

Re: performance problems?

[Ducrot Bruno]

On Tue, Nov 19, 2002 at 10:59:43AM -0500, James D Strandboge wrote:
> On Tue, 2002-11-19 at 09:54, Markus Gaugusch wrote:
> > On Nov 19, Loic Jaquemet <ljaquemet-BNG0eM9rGRi0IRkH3yUr9EW4647UYGdYQQ4Iyu8u01E@public.gmane.org> wrote:
> > > i'am using 2.4.19 + around october patch ( I'll check that this evening )
> > > on sony vaio fx502
> > > [...]
> > > when I fetch the /proc/acpi/<batteriesxxx>/state|info files, I get a 1-2
> > > second freeze| lag ..
> > > [...]
> > > I'm not sure, but i think i didn't have this problem on pre-september
> > > patches ..
> > No, it has been present before. I have an FX405 and can't use any battery
> > monitor applet that reads the info file. Even a 'cat
> > /proc/acpi/battery/BAT1/info' causes a noticable peak in my cpu monitor
> > (kernel time). At least, it doesn't freeze keyboard anymore, thanks to the
> > ACPI people!
> > 
> 
> You want to poll /proc/acpi/battery/BAT1/state or whatever is correct
> for your battery.  Polling info requires interrupts with the BIOS I
> think, and state is there for a quick poll.  At least on my machine this
> is the case.  

Yes and not.  In fact, the ASL code contains some Notification() methods, then
kernel will inform user space via /proc/acpi/event.

Most of the time, those Notification() are generated by an interrupt (certainly
an SCI).
You should see some Notification() to the battery(ies) in a \_GPE.[EL]xx(), or in a
_Qxx() from an embedded controller in that case.

> 
> Perhaps someone would want to clarify the difference and why info causes
> a hang and state does not.

info give 'static' informations, as design capacity, last full technology, etc.
It is 'huge', and do not need to be read often.

state give the actual remaining capacity of the battery, present voltage, and so
on.  It is 'small' and also hold the 'variable' part of the battery.


Now why cat'ing 'info' hang some systems is another
problem (Should Not Happen (c)(tm))...


-- 
Ducrot Bruno
http://www.poupinou.org        Page profaissionelle
http://toto.tu-me-saoules.com  Haume page


-------------------------------------------------------
This sf.net email is sponsored by: To learn the basics of securing 
your web site with SSL, click here to get a FREE TRIAL of a Thawte 
Server Certificate: http://www.gothawte.com/rd524.html

Re: performance problems?

[Thomas List]

James D Strandboge wrote:

>You want to poll /proc/acpi/battery/BAT1/state or whatever is correct
>for your battery.  Polling info requires interrupts with the BIOS I
>think, and state is there for a quick poll.  At least on my machine this
>is the case.  
>
Ah - OK, I am polling info and state at the moment. Let's see what 
happens if I skip info.

  Thomas




-------------------------------------------------------
This sf.net email is sponsored by: To learn the basics of securing 
your web site with SSL, click here to get a FREE TRIAL of a Thawte 
Server Certificate: http://www.gothawte.com/rd524.html

Re: performance problems?

[Malte Thoma]

Markus Gaugusch wrote:
> On Nov 19, Loic Jaquemet <ljaquemet-BNG0eM9rGRi0IRkH3yUr9EW4647UYGdYQQ4Iyu8u01E@public.gmane.org> wrote:
> 
>>i'am using 2.4.19 + around october patch ( I'll check that this evening )
>>on sony vaio fx502
>>[...]
>>when I fetch the /proc/acpi/<batteriesxxx>/state|info files, I get a 1-2
>>second freeze| lag ..
>>[...]
>>I'm not sure, but i think i didn't have this problem on pre-september
>>patches ..
> 
> No, it has been present before. I have an FX405 and can't use any battery
> monitor applet that reads the info file. Even a 'cat
> /proc/acpi/battery/BAT1/info' causes a noticable peak in my cpu monitor
> (kernel time). At least, it doesn't freeze keyboard anymore, thanks to the
> ACPI people!

You can try my 'heatload'. Because I have an Sony, too, I have made a 
workaround for the 'info'-File.
(I'm using an older ACPI-patch for kernel 2.4.18)


Greetings,

Malte




-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: performance problems?

[Nils Faerber]

On Tue, 19 Nov 2002 14:37:26 +0100
Thomas List <Thomas.List-vA1bhqPz9FBZXbeN9DUtxg@public.gmane.org> wrote:
> Hi all,
Hello!

> I'm working on a small battery applet for my laptop that reads out the
> battery status. As I have up to now no better idea I'm pulling the 
> battery status (/proc/acpi/battery/...) every few seconds (anyone an 
> idea of how to do this better?). Now a battery applet should consume
> as few CPU cycles as possible to not use up the battery itself. So I'm
> trying to monitor how much computing time my applet is using. For the 
> moment I'm doing this using top (I know this is not perfect for that 
> task ...). Now to the problem:

IMHO your assumption are coorect.

> After the laptop is running for some time the CPU% value in top is 
> getting higher and higher. It starts with around 0.3% in the
> beginning, after one hour it reaches 1,5% and I had it up to 3% and
> more after a longer time. I am quite sure this is not my applet - I
> can stop the program and restart it and still get the higher values. I
> tried to watch a video in this state and while my program was running
> I had short stops in the video play back that match the 2 seconds
> interval of pulling the battery status. Without my program running the
> stops disappeared. Using a file system copy of /proc/acpi my program
> does not show at all on the top list.

I cannot explain what you are observing but I can confirm your
observations. I see the same "hangs" and CPU usage phenomenon when using
a window-maker dock application showing battery information. Everytime
the battery is polled by the applet the CPU usage rises and the machine
suffers a short hang; approx. 1/4 second.

> I am using acpi 20021111 on a 2.4.20-rc1 kernel. The laptop is a Targa
> visionary 1600 from actebis (mobile athlon on a Via ProSavage KN133 
> "TwisterK" board). I think I did not have such problems with an older 
> acpi version (20021022 ???) - I will check this out).

Same here.
Laptop is Asus L3800C.

> Now could this be a problem with the acpi implementation or is this
> the result of a wrong usage of acpi?

I think this is a problem with ACPI...

> Btw. - is there any documentation on the /proc/acpi directories
> besides Dominik Brodowski's documentation for /proc/acpi/processor?

AFAIK not; but would be nice!

> Thanks for any help,
>    Thomas
CU
  nils faerber

-- 
kernel concepts          Tel: +49-271-771091-12
Dreisbachstr. 24         Fax: +49-271-771091-19
D-57250 Netphen          D1 : +49-170-2729106
--


-------------------------------------------------------
This sf.net email is sponsored by: To learn the basics of securing 
your web site with SSL, click here to get a FREE TRIAL of a Thawte 
Server Certificate: http://www.gothawte.com/rd524.html

Re: performance problems?

[David Douard]

Hi,

not sure about it, but have you any debug info on in ACPI ? Maybe, try to put 
debug info off (echo "0" > /proc/acpi/debug_level ), and see if that change 
anything.
I say that cause I used to have a lag due to debug info (which I must admit I 
put to a quite hight level, producing many data).

For the question about polling, it should be possible, according to specs (if 
I remember well, I'm not very sure) to have ACPI send an exception, thus 
catch it (with ospmd, acpid or whatever daemon you want) only when bat status 
changes. But for now, I have never been able to make my laptop work like 
this... But my compaq has such a buggy DSDT... And maybe probably harware 
bugs too (in interrupts lines)... That's bad cause software polling is never 
the right way to do such things here (temperature monitoring should not be 
polled either... In my DSDT, I have two functions, one which should be called 
when temp grows up,  one for down. None of them is ever called.).

David Douard

Le Mardi 19 Novembre 2002 14:37, Thomas List a écrit :
> Hi all,
>
> I'm working on a small battery applet for my laptop that reads out the
> battery status. As I have up to now no better idea I'm pulling the
> battery status (/proc/acpi/battery/...) every few seconds (anyone an
> idea of how to do this better?). Now a battery applet should consume as
> few CPU cycles as possible to not use up the battery itself. So I'm
> trying to monitor how much computing time my applet is using. For the
> moment I'm doing this using top (I know this is not perfect for that
> task ...). Now to the problem:
>
> After the laptop is running for some time the CPU% value in top is
> getting higher and higher. It starts with around 0.3% in the beginning,
> after one hour it reaches 1,5% and I had it up to 3% and more after a
> longer time. I am quite sure this is not my applet - I can stop the
> program and restart it and still get the higher values. I tried to watch
> a video in this state and while my program was running I had short stops
> in the video play back that match the 2 seconds interval of pulling the
> battery status. Without my program running the stops disappeared.
> Using a file system copy of /proc/acpi my program does not show at all
> on the top list.
>
> I am using acpi 20021111 on a 2.4.20-rc1 kernel. The laptop is a Targa
> visionary 1600 from actebis (mobile athlon on a Via ProSavage KN133
> "TwisterK" board). I think I did not have such problems with an older
> acpi version (20021022 ???) - I will check this out).
>
> Now could this be a problem with the acpi implementation or is this the
> result of a wrong usage of acpi?
>
>
> Btw. - is there any documentation on the /proc/acpi directories besides
> Dominik Brodowski's documentation for /proc/acpi/processor?
>
> Thanks for any help,
>
>    Thomas
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: To learn the basics of securing
> your web site with SSL, click here to get a FREE TRIAL of a Thawte
> Server Certificate: http://www.gothawte.com/rd524.html
> _______________________________________________
> Acpi-devel mailing list
> Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/acpi-devel



-------------------------------------------------------
This sf.net email is sponsored by: To learn the basics of securing 
your web site with SSL, click here to get a FREE TRIAL of a Thawte 
Server Certificate: http://www.gothawte.com/rd524.html

Re: performance problems?

[Ducrot Bruno]

On Tue, Nov 19, 2002 at 03:40:58PM +0100, David Douard wrote:
> Hi,
> 
> not sure about it, but have you any debug info on in ACPI ? Maybe, try to put 
> debug info off (echo "0" > /proc/acpi/debug_level ), and see if that change 
> anything.
> I say that cause I used to have a lag due to debug info (which I must admit I 
> put to a quite hight level, producing many data).
> 
> For the question about polling, it should be possible, according to specs (if 
> I remember well, I'm not very sure) to have ACPI send an exception, thus 

It is called an 'event', but, well, the idea is here.

> catch it (with ospmd, acpid or whatever daemon you want) only when bat status 

Yes.  In fact, you shoud have something like that, when battery info change:

novae:~# cat /proc/acpi/event     
battery BAT1 00000080 00000001
battery BAT2 00000080 00000000


The /proc/acpi/event should be read actually by acpid or by ospmd, thus
those events would be forwarded to an another user space program (as a
battery status monitor).  It would be more easy to have that via
ospmd than with acpid.

In fact, ospmd abstract all this 'detail' for you, and you should
have the current state of the battery(ies), without worrying about
/proc files, by using libpower.

-- 
Ducrot Bruno
http://www.poupinou.org        Page profaissionelle
http://toto.tu-me-saoules.com  Haume page


-------------------------------------------------------
This sf.net email is sponsored by: To learn the basics of securing 
your web site with SSL, click here to get a FREE TRIAL of a Thawte 
Server Certificate: http://www.gothawte.com/rd524.html

Re: performance problems?

[Thomas List]

Hi,

Ducrot Bruno wrote:

>On Tue, Nov 19, 2002 at 03:40:58PM +0100, David Douard wrote:
>  
>
>>catch it (with ospmd, acpid or whatever daemon you want) only when bat status 
>>    
>>
>
>Yes.  In fact, you shoud have something like that, when battery info change:
>
>novae:~# cat /proc/acpi/event     
>battery BAT1 00000080 00000001
>battery BAT2 00000080 00000000
>


OK, I will give it a try with ospmd and maybe the libpower included in 
the ospmd release.  Unluckily I have never seen any event in 
/proc/acpi/event on my laptop so I'm not sure if it's not working at all 
or if it's just misconfigured.

Again, any hint for documentation (for example on /proc/acpi/event or 
ospmd) would be helpful ;)

  Thomas




-------------------------------------------------------
This sf.net email is sponsored by: To learn the basics of securing 
your web site with SSL, click here to get a FREE TRIAL of a Thawte 
Server Certificate: http://www.gothawte.com/rd524.html

RE: performance problems?

[Grover, Andrew]

> From: Nils Faerber [mailto:nils-t93Ne7XHvje5bSeCtf/tX7NAH6kLmebB@public.gmane.org] 
> > Now could this be a problem with the acpi implementation or is this
> > the result of a wrong usage of acpi?
> 
> I think this is a problem with ACPI...

Yep.

Clearly we are doing something wrong. But, we're not sure what. It only
happens on some systems, so we're kinda in "change something, did that fix
it? no? try this." mode.

We changed mutex handling in the release yesterday - there's a *slight*
chance that was the needed fix. Can you try that patch?

Other than that, maybe the best way is to call
acpi_set_debug(ACPI_DEBUG_HIGH) in the battery driver right before we
evaluate _BIF, and see where it's spending all its time.

Regards -- Andy


-------------------------------------------------------
This sf.net email is sponsored by: To learn the basics of securing 
your web site with SSL, click here to get a FREE TRIAL of a Thawte 
Server Certificate: http://www.gothawte.com/rd524.html

Re: performance problems?

[Thomas List]

Grover, Andrew wrote:

>Clearly we are doing something wrong. But, we're not sure what. It only
>happens on some systems, so we're kinda in "change something, did that fix
>it? no? try this." mode.
>
>We changed mutex handling in the release yesterday - there's a *slight*
>chance that was the needed fix. Can you try that patch?
>
I will give it a try when I find the time. As Jamie Strandboge proposed 
I stopped polling the info file. This did give a huge improvement. As 
described in my first mail the short stops increased when the system was 
running longer and longer. This for now is gone without touching the 
info file.

  Thomas





-------------------------------------------------------
This sf.net email is sponsored by: To learn the basics of securing 
your web site with SSL, click here to get a FREE TRIAL of a Thawte 
Server Certificate: http://www.gothawte.com/rd524.html

RE: performance problems?

[Markus Gaugusch]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1196 bytes --]

On Nov 19, Grover, Andrew <andrew.grover-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:
> Clearly we are doing something wrong. But, we're not sure what. It only
> happens on some systems, so we're kinda in "change something, did that fix
> it? no? try this." mode.
>
> We changed mutex handling in the release yesterday - there's a *slight*
> chance that was the needed fix. Can you try that patch?
>
> Other than that, maybe the best way is to call
> acpi_set_debug(ACPI_DEBUG_HIGH) in the battery driver right before we
> evaluate _BIF, and see where it's spending all its time.
Hi, I tried what you suggested (you forgot to tell to set ACPI_DEBUG_LOW
at end of function, but I learnt rather fast ;)

Attached are my dsdt and the messages while inserting the battery.o module
and a few seconds later cat /proc/acpi/battery/BAT1/info.

Most noticeable is a Exception AE_BUFFER_OVERFLOW, but you can see
yourself. Without debugging it still does have a noticeable delay
(~0.5sec)

kind regards,
Markus Gaugusch

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

[-- Attachment #2: Type: APPLICATION/x-gunzip, Size: 9329 bytes --]

[-- Attachment #3: Type: APPLICATION/x-gunzip, Size: 7621 bytes --]