reading files in /proc/acpi hangs machine for a short time

reading files in /proc/acpi hangs machine for a short time

[wwp]

Hi there,


many acpi programs that show the battery/etc. usage that I tested are making
my system not to respond for a very short while, but periodically. For
instance, the mouse is being locked for 1/n of a second, which is not a big
loss of performance, but it really damn itchy for a normal (intensive) usage
of my Dell Inspiron 8200 laptop (kernel 2.4.26). I do remember of some
programs that were not producing such itchyness a long time ago (maybe
because the kernel things were different?).

I've found that if I some files from /proc/acpi (let's say battery state), I
get the same behaviour.

So my questions are:
- is this a known issue?
- program/kernel/dsdt/what-else issued?
- are there known workarounds?
- is it possible to get the acpi states from another place that /proc (if only it
doesn't show the same problem)?


Regards,

-- 
wwp


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: reading files in /proc/acpi hangs machine for a short time

[Michael Frank]

On Fri, 25 Jun 2004 08:29:29 +0200, wwp <subscript-GANU6spQydw@public.gmane.org> wrote:

> Hi there,
>
>
> many acpi programs that show the battery/etc. usage that I tested are making
> my system not to respond for a very short while, but periodically. For
> instance, the mouse is being locked for 1/n of a second, which is not a big
> loss of performance, but it really damn itchy for a normal (intensive) usage
> of my Dell Inspiron 8200 laptop (kernel 2.4.26). I do remember of some
> programs that were not producing such itchyness a long time ago (maybe
> because the kernel things were different?).
>
> I've found that if I some files from /proc/acpi (let's say battery state), I
> get the same behaviour.
>
> So my questions are:
> - is this a known issue?
> - program/kernel/dsdt/what-else issued?
> - are there known workarounds?
> - is it possible to get the acpi states from another place that /proc (if only it
> doesn't show the same problem)?
>

First figure out whether it is the PM app or ACPI.

1) Disable all PM apps touching /proc/acpi.

2) In a seperate terminal or VT run a script like

while :; do cat /proc/acpi/xxx/xxx/what_you_want_to_test > /dev/null; usleep 300000; done

Example sleeps 300ms (300000us) after every read, try various settings
 from as low as 100ms to 10s and see how you system behaves.

If you don't have usleep sleep will do in 1s increments...

Note also can try cat /proc/acpi/battery/*/*

Run it continuously in the background and hopefully the test will show problems
due to ACPI proc accesses. If not, the PM  apps are the problem - are these running
big scripts or impose high system load somehow?


	Regards




-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com

Re: reading files in /proc/acpi hangs machine for a short time

[wwp]

Hello Michael,


On Fri, 25 Jun 2004 19:29:54 +0800 "Michael Frank" <mhf-jjFNsPSvq+iXDw4h08c5KA@public.gmane.org> wrote:

> On Fri, 25 Jun 2004 08:29:29 +0200, wwp <subscript-GANU6spQydw@public.gmane.org> wrote:
> 
> > Hi there,
> >
> > many acpi programs that show the battery/etc. usage that I tested are making
> > my system not to respond for a very short while, but periodically. For
> > instance, the mouse is being locked for 1/n of a second, which is not a big
> > loss of performance, but it really damn itchy for a normal (intensive) usage
> > of my Dell Inspiron 8200 laptop (kernel 2.4.26). I do remember of some
> > programs that were not producing such itchyness a long time ago (maybe
> > because the kernel things were different?).
> >
> > I've found that if I some files from /proc/acpi (let's say battery state), I
> > get the same behaviour.
> >
> > So my questions are:
> > - is this a known issue?
> > - program/kernel/dsdt/what-else issued?
> > - are there known workarounds?
> > - is it possible to get the acpi states from another place that /proc (if only it
> > doesn't show the same problem)?
> >
> 
> First figure out whether it is the PM app or ACPI.
> 
> 1) Disable all PM apps touching /proc/acpi.
> 
> 2) In a seperate terminal or VT run a script like
> 
> while :; do cat /proc/acpi/xxx/xxx/what_you_want_to_test > /dev/null; usleep 300000; done
> 
> Example sleeps 300ms (300000us) after every read, try various settings
>  from as low as 100ms to 10s and see how you system behaves.
> 
> If you don't have usleep sleep will do in 1s increments...
> 
> Note also can try cat /proc/acpi/battery/*/*
> 
> Run it continuously in the background and hopefully the test will show problems
> due to ACPI proc accesses. If not, the PM  apps are the problem - are these running
> big scripts or impose high system load somehow?

Thanks for your reply :-).

Excepted acpid 1.0.3, no (known) tool is playing with ACPI. When I run
wmpower/wmacpi or some other ACPI-aware PM tools, or if I do cat
/proc/acpi/battery/*/* by myself, then I can see the slowlyness (the period
depends on the wmpower refresh rate, or how often I do cat /proc/acpi/...).

Without any of these attempts (wmpower or cat /proc/acpi/...), my system
behaves normally. So it seems to me that accessing to files ini
/proc/acpi/bla/bla from C code or script behaves the same, it slows down the
machine for a very short while, because of CPU eating.


Regards,

-- 
wwp


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: reading files in /proc/acpi hangs machine for a short time

[Michael Frank]

On Fri, 25 Jun 2004 13:50:36 +0200, wwp <subscript-GANU6spQydw@public.gmane.org> wrote:

> Hello Michael,
>
>
> On Fri, 25 Jun 2004 19:29:54 +0800 "Michael Frank" <mhf-jjFNsPSvq+iXDw4h08c5KA@public.gmane.org> wrote:
>
>> On Fri, 25 Jun 2004 08:29:29 +0200, wwp <subscript-GANU6spQydw@public.gmane.org> wrote:
>>
>> > Hi there,
>> >
>> > many acpi programs that show the battery/etc. usage that I tested are making
>> > my system not to respond for a very short while, but periodically. For
>> > instance, the mouse is being locked for 1/n of a second, which is not a big
>> > loss of performance, but it really damn itchy for a normal (intensive) usage
>> > of my Dell Inspiron 8200 laptop (kernel 2.4.26). I do remember of some
>> > programs that were not producing such itchyness a long time ago (maybe
>> > because the kernel things were different?).
>> >
>> > I've found that if I some files from /proc/acpi (let's say battery state), I
>> > get the same behaviour.
>> >
>> > So my questions are:
>> > - is this a known issue?
>> > - program/kernel/dsdt/what-else issued?
>> > - are there known workarounds?
>> > - is it possible to get the acpi states from another place that /proc (if only it
>> > doesn't show the same problem)?
>> >
>>
>> First figure out whether it is the PM app or ACPI.
>>
>> 1) Disable all PM apps touching /proc/acpi.
>>
>> 2) In a seperate terminal or VT run a script like
>>
>> while :; do cat /proc/acpi/xxx/xxx/what_you_want_to_test > /dev/null; usleep 300000; done
>>
>> Example sleeps 300ms (300000us) after every read, try various settings
>>  from as low as 100ms to 10s and see how you system behaves.
>>
>> If you don't have usleep sleep will do in 1s increments...
>>
>> Note also can try cat /proc/acpi/battery/*/*
>>
>> Run it continuously in the background and hopefully the test will show problems
>> due to ACPI proc accesses. If not, the PM  apps are the problem - are these running
>> big scripts or impose high system load somehow?
>
> Thanks for your reply :-).
>
> Excepted acpid 1.0.3, no (known) tool is playing with ACPI. When I run
> wmpower/wmacpi or some other ACPI-aware PM tools, or if I do cat
> /proc/acpi/battery/*/* by myself, then I can see the slowlyness (the period
> depends on the wmpower refresh rate, or how often I do cat /proc/acpi/...).
>
> Without any of these attempts (wmpower or cat /proc/acpi/...), my system
> behaves normally. So it seems to me that accessing to files ini
> /proc/acpi/bla/bla from C code or script behaves the same, it slows down the
> machine for a very short while, because of CPU eating.
>

Should not be like that. I have not encountered it on 2.4

Suggest you file a bug report in kernel bugzilla with details of you HW
so it gets looked into. Get some details of which files cause the problems
using the script and enclose the script as well.

	Regards


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com

Re: reading files in /proc/acpi hangs machine for a short time

[Stefan Seyfried]

On Fri, Jun 25, 2004 at 11:57:33PM +0800, Michael Frank wrote:

> >behaves normally. So it seems to me that accessing to files ini
> >/proc/acpi/bla/bla from C code or script behaves the same, it slows down 
> >the
> >machine for a very short while, because of CPU eating.
> 
> Should not be like that. I have not encountered it on 2.4

I have seen this in 2.4 kernels on e.g. asus l8400, reading the
battery. It even lead to "lost time" in the kernel clock (often
reading the battery slowed down the clock considerably). IIUC this
is caused by bad hardware design (battery controllers connected via 
i2c or similar slow serial buses read with busy loops or something 
ugly like that.
It seems this has been resolved in 2.6.

On some hardware, reading battery is still very expensive (causes small
peaks of high load in kernel space) on others it is not. At least i don't
think i saw the clock losing ticks in 2.6.

> Suggest you file a bug report in kernel bugzilla with details of you HW
> so it gets looked into. Get some details of which files cause the problems
> using the script and enclose the script as well.

I am not sure that there can be done much about this if the particular
hardware is badly designed.
-- 
Stefan Seyfried



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com