Re: ACPI idle performance problem

[Andrew Doran <ad%netbsd.org@localhost>]

Hi Jukka,

On Thu, May 28, 2020 at 07:18:40AM +0300, Jukka Ruohonen wrote:
> On Tue, Mar 03, 2020 at 10:12:29PM +0000, Andrew Doran wrote:
> > So this is burning power/CPU rather than saving it.  On the face of it I
> > think we should put acpicpu's idle method under an option and come back to
> > making it the default once the kinks are worked out, unless I have missed
> > something.
> 
> A little more about this: if we consider only the P-states for the time
> being (a.k.a. frequency scaling), the flag ACPICPU_DEP_SW_ANY indicates that
> per-CPU (or per-CPU-group) states (frequencies) are possible.
> 
> So my original idea was that controls could be done with cpuctl(8) via an
> ioctl. I had this working at some point, but I seem to have lost the patch. 
> Besides allowing fine-grained controls (e.g., setting a frequency to the
> minimum when putting a CPU offline), this would allow eventually deprecating
> the sysctl nodes.

I haven't seen any problem with that stuff, and I don't think it's related
to the specific problem that I have been seeing.

I spent a bit of time playing with this over the weekend, instrumented the
code to find out what was happening and and made a commit to
acpi_cpu_cstate.c work around the problem.  There are a couple of comments
in there explaining what I found but basically reading the ACPI timer
(mapped via I/O port) during idle seems stupidly costly, enough to add
between 5-10% system time to a kernel build for me.

I guess the system builders don't pay attention to I/O port access since
most devices are memory mapped now.

Cheers,
Andrew