ACPI slowdown...

ACPI slowdown...

[Tony Hoyle]

I've been trying to track down what makes ACPI kill the system in 2.4.1.

In the acpi_idle function (drivers/acpi/cpu.c), it seems to spend most 
of its time with interrupts disabled, only enabling them to check 
need_resched occasionally.

In the 'sleep1' state the following code is executed:

         for (;;) {
                 unsigned long time;
                 unsigned long diff;

                 __cli();
                 if (current->need_resched)
                         goto out;
                 time = acpi_read_pm_timer();
                 safe_halt();
                 diff = acpi_compare_pm_timers(time, acpi_read_pm_timer());
                 if (diff > acpi_c2_enter_latency
                     && acpi_max_c_state >= 2)
                         goto sleep2;
         }

This looks wrong to me.  It's basically looping with interrupts 
disabled.  I can't see how current->need_resched could be updated at 
all, so the loop will only terminate when the PM timer tells it to.

Isn't disabling interrupts a bad thing anyway?  Wouldn't it be better to 
leave them enabled (this is uniprocessor only so there shouldn't be 
concurrency issues).

Tony

-- 

The only secure computer is one that's unplugged, locked in a safe,
and buried 20 feet under the ground in a secret location... and i'm
not even too sure about that one"--Dennis Huges, FBI.

tmh@magenta-netlogic.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: ACPI slowdown...

[Tony Hoyle]

Tony Hoyle wrote:

I'm talking to myself :-)

OK I see that safe_halt() will re-enable interrupts.  However this is only
called in S1.  If your machine gets as far as S3 you have...

         for (;;) {
                 unsigned long time;
                 unsigned long diff;

                 __cli();
                 if (current->need_resched)
                         goto out;
                 if (acpi_bm_activity())
                         goto sleep2;

                 time = acpi_read_pm_timer();
                 inb(acpi_pblk + ACPI_P_LVL3);
                 /* Dummy read, force synchronization with the PMU */
                 acpi_read_pm_timer();
                 diff = acpi_compare_pm_timers(time, acpi_read_pm_timer());

                 __sti();
                 if (diff < acpi_c3_exit_latency)
                         goto sleep2;
         }

There is no halt here... the interrupts are enabled for only a couple of 
instructions (one comparison and a jump) before being disabled again. 
It seems to me if the computer gets into S3 it'll effectively die until 
some kind of busmaster device wakes it up (DMA?).

The simple fix is to delete lines 332-337 of cpu.c, which disables the 
idle process (and explains why I've had no slowdown on my SMP machine). 
  Lots of people (like me) only use ACPI for the power-off/shutdown 
functionality anyway.  Laptop users will probably have to wait for a 
proper fix (unfortunately the ACPI4Linux mailing list looks dead - it's 
just full of people complaining about 2.4.1...)

Tony

-- 

The only secure computer is one that's unplugged, locked in a safe,
and buried 20 feet under the ground in a secret location... and i'm
not even too sure about that one"--Dennis Huges, FBI.

tmh@magenta-netlogic.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: ACPI slowdown...

[Pavel Machek]

Hi!

> Tony Hoyle wrote:
> 
> I'm talking to myself :-)
> 
> OK I see that safe_halt() will re-enable interrupts.  However this is only
> called in S1.  If your machine gets as far as S3 you have...
> 
>          for (;;) {
>                  unsigned long time;
>                  unsigned long diff;
> 
>                  __cli();
>                  if (current->need_resched)
>                          goto out;
>                  if (acpi_bm_activity())
>                          goto sleep2;
> 
>                  time = acpi_read_pm_timer();
>                  inb(acpi_pblk + ACPI_P_LVL3);
>                  /* Dummy read, force synchronization with the PMU */
>                  acpi_read_pm_timer();
>                  diff = acpi_compare_pm_timers(time, acpi_read_pm_timer());
> 
>                  __sti();
>                  if (diff < acpi_c3_exit_latency)
>                          goto sleep2;
>          }
> 
> There is no halt here... the interrupts are enabled for only a couple of 
> instructions (one comparison and a jump) before being disabled again. 
> It seems to me if the computer gets into S3 it'll effectively die until 
> some kind of busmaster device wakes it up (DMA?).

No.

If interrupts come in cli-ed section, it will be postponed until
sti. It then comes, and sets need_resched and recovers.

								Pavel
-- 
I'm pavel@ucw.cz. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at discuss@linmodems.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

RE: ACPI slowdown...

[Grover, Andrew]

> From: Tony Hoyle [mailto:tmh@magenta-netlogic.com]
> OK I see that safe_halt() will re-enable interrupts.  However 
> this is only
> called in S1.  If your machine gets as far as S3 you have...

I think you mean C1 and C3, but I know what you mean.. :)

[C3 code snipped]

> There is no halt here... the interrupts are enabled for only 
> a couple of 
> instructions (one comparison and a jump) before being disabled again. 
> It seems to me if the computer gets into S3 it'll effectively 
> die until 
> some kind of busmaster device wakes it up (DMA?).

The problem I've had in fixing this code is that it WorksForMe(TM). I cannot
reproduce the problem on my machine (an IBM T20). That's the way the code
was, so I left it (the code I changed/broke was the C2/C3 latency calcs).

Since you have a symtomatic system, if you're willing to do some testing to
either prove or disprove your theory (that entering C2/C3 interrupts enabled
helps things) I would greatly appreciate it.

Also, the next ACPI update will let you disable using this code for idle (so
we have some breathing room while we fix it) and will print some more C
state info on boot, because although you don't say, it sounds like you have
a desktop system, which usually don't support C2/C3, and so should not be
trying to enter them.

Regards -- Andy
(ACPI maintainer)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: ACPI slowdown...

[Tony Hoyle]

Grover, Andrew wrote:

> Since you have a symtomatic system, if you're willing to do some testing to
> either prove or disprove your theory (that entering C2/C3 interrupts enabled
> helps things) I would greatly appreciate it.

Leaving interrupts enabled does help a little, but the machine is still 
unusably slow, so it's not the fix.

 
> Also, the next ACPI update will let you disable using this code for idle (so
> we have some breathing room while we fix it) and will print some more C
> state info on boot, because although you don't say, it sounds like you have
> a desktop system, which usually don't support C2/C3, and so should not be
> trying to enter them.

Disabling the idle code definitely fixes it.

Tony


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/