Entering C3 Processor State without a Bus Arbiter

Entering C3 Processor State without a Bus Arbiter

[Dino Klein]

Hello,

I'm curios as to why the implementation does not enter C3 without the presence of a Bus Arbiter; also, how come a comment in the
source claims that C3/WBINVD is too expensive?

After removing the restrictions in the source files, and adding a WBINVD instruction right before the read from P_LVL3 - the
processor was put in the C3 state. This is on my Via Apollo Pro133A based Abit VP6 board, which does not have a Bus Arbiter.
Just for the record, I did pull out the second CPU, so I can do "safer" experimentation.

Everything seemed to be working fine, the delay was quite noticeable (900 in the FACP) to the point that keystrokes were lost. In
essence, the computer was quite unusable. Nevertheless, in order to see if the system was still stable after the modifications, I
recompiled the kernel with "-j8" and everything worked fine; I even started X without problems.

I've seen a thread talking about how the processor was not put into C3 as often enough, when the USB drivers were loaded - in my
case I would say that it was put too often, this with the UHCI + EHCI + HID drivers loaded, and two mice and one hub attached.

Just thought I'd bring this up.


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: Entering C3 Processor State without a Bus Arbiter

[Dominik Brodowski]

[-- Attachment #1: Type: text/plain, Size: 987 bytes --]

On Thu, Jan 15, 2004 at 05:29:23PM -0500, Dino Klein wrote:
> Hello,
> 
> I'm curios as to why the implementation does not enter C3 without the presence of a Bus Arbiter; also, how come a comment in the
> source claims that C3/WBINVD is too expensive?

[ /me shuffles in some old directories and finds a file called wbinvd_analysis ]

I'd investigated this a couple of months ago. It turned out to hang my
(previous) notebook every once in a while; I think that was the reason I
aborted the patch...

The average cost of a wbinvd instruction was 98us, the minimum cost 22us.
However, the  maximum cost was a horrible 780us. The average sleeping time
of C3 was 519us, minimum 0us...

This is discussed in detail in these threads:
http://marc.theaimsgroup.com/?l=acpi4linux&m=101630988127506&w=2
http://marc.theaimsgroup.com/?l=acpi4linux&m=101662029010850&w=2

other threads (including my patches) can be found by searching for "wbinvd"
in this archive.

	Dominik

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Entering C3 Processor State without a Bus Arbiter

[Nate Lawson]

On Thu, 15 Jan 2004, Dino Klein wrote:
> I'm curios as to why the implementation does not enter C3 without the
> presence of a Bus Arbiter; also, how come a comment in the source claims
> that C3/WBINVD is too expensive?
>
> After removing the restrictions in the source files, and adding a WBINVD
> instruction right before the read from P_LVL3 - the processor was put in
> the C3 state. This is on my Via Apollo Pro133A based Abit VP6 board,
> which does not have a Bus Arbiter. Just for the record, I did pull out
> the second CPU, so I can do "safer" experimentation.

WBINVD is too expensive when you're entering C3 hundreds of times per
second.  Try playing back an mp3 while dd'ing a CDROM in PIO mode to your
hard drive.  Goodbye data, hello backups!  The CPU can't snoop the bus in
C3.

> I've seen a thread talking about how the processor was not put into C3
> as often enough, when the USB drivers were loaded - in my case I would
> say that it was put too often, this with the UHCI + EHCI + HID drivers
> loaded, and two mice and one hub attached.

Um, because without BM detection, you're entering C3 with BM active while
USB is enabled.

-Nate


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: Entering C3 Processor State without a Bus Arbiter

[Dominik Brodowski]

[-- Attachment #1: Type: text/plain, Size: 1012 bytes --]

On Thu, Jan 15, 2004 at 03:52:12PM -0800, Nate Lawson wrote:
> > After removing the restrictions in the source files, and adding a WBINVD
> > instruction right before the read from P_LVL3 - the processor was put in
> > the C3 state. This is on my Via Apollo Pro133A based Abit VP6 board,
> > which does not have a Bus Arbiter. Just for the record, I did pull out
> > the second CPU, so I can do "safer" experimentation.
> 
> WBINVD is too expensive when you're entering C3 hundreds of times per
> second.  Try playing back an mp3 while dd'ing a CDROM in PIO mode to your
> hard drive.  Goodbye data, hello backups!  The CPU can't snoop the bus in
> C3.

You shouldn't enter C3 at all when the CPU is woken up hundreds of times per
second. Maximum allowed latency is 1ms, IIRC -- you really shouldn't get
into this state while dd'ing a CDROM or something else...

Problem is, WBINVD might take even longer than 1ms, even though the maximum
I got on my PIII notebook was about 900us...

	Dominik

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Entering C3 Processor State without a Bus Arbiter

[Nate Lawson]

On Fri, 16 Jan 2004, Dominik Brodowski wrote:
> On Thu, Jan 15, 2004 at 03:52:12PM -0800, Nate Lawson wrote:
> > > After removing the restrictions in the source files, and adding a WBINVD
> > > instruction right before the read from P_LVL3 - the processor was put in
> > > the C3 state. This is on my Via Apollo Pro133A based Abit VP6 board,
> > > which does not have a Bus Arbiter. Just for the record, I did pull out
> > > the second CPU, so I can do "safer" experimentation.
> >
> > WBINVD is too expensive when you're entering C3 hundreds of times per
> > second.  Try playing back an mp3 while dd'ing a CDROM in PIO mode to your
> > hard drive.  Goodbye data, hello backups!  The CPU can't snoop the bus in
> > C3.
>
> You shouldn't enter C3 at all when the CPU is woken up hundreds of times per
> second. Maximum allowed latency is 1ms, IIRC -- you really shouldn't get
> into this state while dd'ing a CDROM or something else...
>
> Problem is, WBINVD might take even longer than 1ms, even though the maximum
> I got on my PIII notebook was about 900us...

The processor code in Linux degrades to C2 when the last sleep was less
than its latency.  So if you have 900 us C3 latency, you can be woken up a
thousand times a second without degrading to C2.

The other, more important point I was trying to make is that without a BM
control, he won't get awoken for BM events and there will be DMA
underruns.  The issue with C3 is both latency and BM events.

-Nate


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: Entering C3 Processor State without a Bus Arbiter

[Dominik Brodowski]

[-- Attachment #1: Type: text/plain, Size: 444 bytes --]

On Fri, Jan 16, 2004 at 09:33:05AM -0800, Nate Lawson wrote:
> The processor code in Linux degrades to C2 when the last sleep was less
> than its latency.  So if you have 900 us C3 latency, you can be woken up a
> thousand times a second without degrading to C2.

Well, then maybe the Cx policy code is something which needs to be looked
at... will do that when I implement _CST support [soon, as my notebook wants
to be put into C4]

	Dominik

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Entering C3 Processor State without a Bus Arbiter

[Dino Klein]

> On Fri, 16 Jan 2004, Dominik Brodowski wrote:
> > On Thu, Jan 15, 2004 at 03:52:12PM -0800, Nate Lawson wrote:
> > > > After removing the restrictions in the source files, and adding a
WBINVD
> > > > instruction right before the read from P_LVL3 - the processor was
put in
> > > > the C3 state. This is on my Via Apollo Pro133A based Abit VP6 board,
> > > > which does not have a Bus Arbiter. Just for the record, I did pull
out
> > > > the second CPU, so I can do "safer" experimentation.
> > >
> > > WBINVD is too expensive when you're entering C3 hundreds of times per
> > > second.  Try playing back an mp3 while dd'ing a CDROM in PIO mode to
your
> > > hard drive.  Goodbye data, hello backups!  The CPU can't snoop the bus
in
> > > C3.
> >
> > You shouldn't enter C3 at all when the CPU is woken up hundreds of times
per
> > second. Maximum allowed latency is 1ms, IIRC -- you really shouldn't get
> > into this state while dd'ing a CDROM or something else...
> >
> > Problem is, WBINVD might take even longer than 1ms, even though the
maximum
> > I got on my PIII notebook was about 900us...
>
> The processor code in Linux degrades to C2 when the last sleep was less
> than its latency.  So if you have 900 us C3 latency, you can be woken up a
> thousand times a second without degrading to C2.
>
> The other, more important point I was trying to make is that without a BM
> control, he won't get awoken for BM events and there will be DMA
> underruns.  The issue with C3 is both latency and BM events.
>
> -Nate
>

I've tried - for the sake of experimenation - the following:
I've modified the code, so that before entering C3, it sets the
ACPI_BITREG_BUS_MASTER_RLD to Zero, instead of One. Then I did a "dd
if=/dev/hda of=somefile bs=32768 count=16384" to dump 512MB from /dev/hda to
somefile on /dev/hdb. The operation took 125 seconds. The drives are in a
master-slave relationship, and according to info in /proc/ide, hda is set to
UDMA100, and hdb to UDMA66.
All this on my board without the Bus Arbiter, and the addition of the WBINVD
call that I put in right before reading P_LVL3.
There was no indication in the logs as to DMA underruns, and the processors
was entering the C3 state while transferring.

Perhaps I don't totally understand this whole BM thing, so I hope I'm not
saying total nonsense here.


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: Entering C3 Processor State without a Bus Arbiter

[Ducrot Bruno]

On Fri, Jan 16, 2004 at 07:02:25PM +0100, Dominik Brodowski wrote:
> On Fri, Jan 16, 2004 at 09:33:05AM -0800, Nate Lawson wrote:
> > The processor code in Linux degrades to C2 when the last sleep was less
> > than its latency.  So if you have 900 us C3 latency, you can be woken up a
> > thousand times a second without degrading to C2.
> 
> Well, then maybe the Cx policy code is something which needs to be looked
> at... will do that when I implement _CST support [soon, as my notebook wants
> to be put into C4]
> 

I have some experimental code for, will cleanup this, and send this to
you soon if you are OK.

Cheers,

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

RE: Entering C3 Processor State without a Bus Arbiter

[Yu, Luming]

> I'm curios as to why the implementation does not enter C3 
> without the presence of a Bus Arbiter; also, how come a comment in the
> source claims that C3/WBINVD is too expensive?

Promoting too soon to C3 could cause performance issues.


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn