Date: Sun, 1 Sep 2013 15:40:01 GMT From: Mike Harding <mvharding@gmail.com> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/181632: 9.2-RC3 - on resume from suspend, disk operations are slower Message-ID: <201309011540.r81Fe1Yc064770@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/181632; it has been noted by GNATS. From: Mike Harding <mvharding@gmail.com> To: Andriy Gapon <avg@freebsd.org> Cc: bug-followup@freebsd.org Subject: Re: kern/181632: 9.2-RC3 - on resume from suspend, disk operations are slower Date: Sun, 1 Sep 2013 08:34:02 -0700 --047d7bb0435c686c9204e5542fed Content-Type: text/plain; charset=ISO-8859-1 Yes, I did notice the list of things to check. Nothing significant is different in the cpu states (just temperature, etc.), no hcpi differences, and no processes returned by your code fragment. I have isolated my issue to this particular line of code, which has been changed (from my point of view) in 9.2-RC and different in 9.1. It is 100% repeatable. No previous released version of FreeBSD has this change in it. You introduced it, if it caused 'increased power consumption and heat production" with the previous version, it would have been noticed by now I think. As you point out, it runs rarely. I only see this issue after a suspend/resume on a desktop machine, which is not something most people do, I am sure. The only place I see the disable idle calls in this file are acpi_cpu_shutdown, acpi_cpu_suspend, and acpi_cpu_startup. It's possible that introducing a 'hlt' into the code path in these calls is causing a deadlock, race condition, or other issue that is not immediately obvious. The only symptom I have is that disk operations are very slow, which is probably an interrupt issue or hardware suspend/resume issue. I am running a pretty generic system (Intel I5 750, Asus motherboard). It is 100% repeatable, do you have a machine with multiple CPUs that you can try this with? Do you have a machine with working suspend/resume? Given that the line in question appears to only run during startup, suspend/resume and shutdown, I think that reverting this -single line- to the version that has run on previous released versions of FreeBSD rather than a version that causes a demonstrated issue is prudent. The only difference should be that a 'hlt' call will not occur during startup, shutdown or suspend, which are very short transitions. I am using an Intel i5 750 with this motherboard: http://www.asus.com/Motherboards/P7P55D/, which is running fairly common hardware. Is there anything else I can do? I can give you ssh access to the system in question. On Sat, Aug 31, 2013 at 11:39 PM, Andriy Gapon <avg@freebsd.org> wrote: > on 31/08/2013 20:05 Mike Harding said the following: > > I reverted the single line at > > > > > http://svnweb.freebsd.org/base/stable/9/sys/dev/acpica/acpi_cpu.c?annotate=244616&pathrev=244616#l978 > > Thank you for narrowing this down! > > > Given that the code says > > > > /* If disabled, take the safe path. */ > > 977 if (is_idle_disabled(sc)) { > > 978 acpi_cpu_c1(); > > 979 return; > > 980 } > > > > > > and then does a 'hlt' or idle if idle is disabled, this might be a > problem. > > But it should not be a problem. > > First, is_idle_disabled should not be normally set. It is supposed to be > set > only during short transitional periods. So it would be useful to > understand why > it is set (after resume) and makes the difference. > > Second, "idle is disabled" means that the ACPI C-state machine is > disabled, not > that the system must not idle at all. In fact, being in this function > (acpi_cpu_idle) means that the system explicitly wants to idle. Using hlt > to > idle is the right / normal / safe thing. Not using hlt means that the > system > keeps burning cycles even when it has nothing to do. So with your change > you > should observe increased power consumption and heat production. > So, this is another mystery as to why the perfectly normal use of hlt > affects > your system so badly. > > P.S. I hope that you noticed a list of things to look at in my previous > followup > to this PR. > -- > Andriy Gapon > --047d7bb0435c686c9204e5542fed Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div><div><div><div><div><div><div>Yes, I did notice the l= ist of things to check.=A0 Nothing significant is different<br></div>in the= cpu states (just temperature, etc.), no hcpi differences, and no<br></div>= processes returned by your code fragment.<br> <br></div>I have isolated my issue to this particular line of code, which h= as been changed<br></div><div>(from my point of view) in 9.2-RC and differe= nt in 9.1.=A0 It is 100% repeatable.<br></div><div>No previous released ver= sion of FreeBSD has this change in it.=A0 You<br> introduced it, if it caused 'increased power consumption and heat produ= ction"<br></div><div>with the previous version, it would have been not= iced by now I think.<br>As you point out, it runs rarely.=A0 I only see thi= s issue after a suspend/resume<br> on a desktop machine, which is not something most people do, I am sure.<br>= </div><div><br></div><div>The only place I see the disable idle calls in th= is file are acpi_cpu_shutdown,<br>acpi_cpu_suspend, and acpi_cpu_startup.= =A0 It's possible that introducing<br> </div><div>a 'hlt' into the code path in these calls is causing a d= eadlock, race condition,<br></div><div>or other issue that is not immediate= ly obvious.=A0 The only symptom I have is<br>that disk operations are very = slow, which is probably an interrupt issue or<br> </div><div>hardware suspend/resume issue.<br></div><div><br></div>I am runn= ing a pretty generic system (Intel I5 750, Asus<br></div>motherboard).=A0 I= t is 100% repeatable, do you have a machine with multiple<br></div><div>CPU= s that you can try this with?=A0 Do you have a machine with working<br> suspend/resume?<br><br></div><div>Given that the line in question appears t= o only run during startup, suspend/resume<br>and shutdown, I think that rev= erting this -single line- to the version that has run<br>on previous releas= ed versions of FreeBSD rather than a version that causes a <br> demonstrated issue is prudent.=A0 The only difference should be that a '= ;hlt'<br></div><div>call will not occur during startup, shutdown or sus= pend, which are very<br>short transitions.<br></div><div><br></div><div>I a= m using an Intel i5 750 with this motherboard: <a href=3D"http://www.asus.c= om/Motherboards/P7P55D/">http://www.asus.com/Motherboards/P7P55D/</a>,<br> </div><div>which is running fairly common hardware.<br><br></div><div>Is th= ere anything else I can do?=A0 I can give you ssh access to the system in<b= r>question.<br></div></div></div><div class=3D"gmail_extra"><br><br><div cl= ass=3D"gmail_quote"> On Sat, Aug 31, 2013 at 11:39 PM, Andriy Gapon <span dir=3D"ltr"><<a hre= f=3D"mailto:avg@freebsd.org" target=3D"_blank">avg@freebsd.org</a>></spa= n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b= order-left:1px #ccc solid;padding-left:1ex"> on 31/08/2013 20:05 Mike Harding said the following:<br> <div class=3D"im">> I reverted the single line at<br> ><br> > <a href=3D"http://svnweb.freebsd.org/base/stable/9/sys/dev/acpica/acpi= _cpu.c?annotate=3D244616&pathrev=3D244616#l978" target=3D"_blank">http:= //svnweb.freebsd.org/base/stable/9/sys/dev/acpica/acpi_cpu.c?annotate=3D244= 616&pathrev=3D244616#l978</a><br> <br> </div>Thank you for narrowing this down!<br> <div class=3D"im"><br> > Given that the code says<br> ><br> > /* If disabled, take the safe path. */<br> > 977 =A0 if (is_idle_disabled(sc)) {<br> > 978 =A0 acpi_cpu_c1();<br> > 979 =A0 return;<br> > 980 =A0 }<br> ><br> ><br> > and then does a 'hlt' or idle if idle is disabled, this might = be a problem.<br> <br> </div>But it should not be a problem.<br> <br> First, is_idle_disabled should not be normally set. =A0It is supposed to be= set<br> only during short transitional periods. =A0So it would be useful to underst= and why<br> it is set (after resume) and makes the difference.<br> <br> Second, "idle is disabled" means that the ACPI C-state machine is= disabled, not<br> that the system must not idle at all. =A0In fact, being in this function<br= > (acpi_cpu_idle) means that the system explicitly wants to idle. =A0Using hl= t to<br> idle is the right / normal / safe thing. =A0Not using hlt means that the sy= stem<br> keeps burning cycles even when it has nothing to do. =A0So with your change= you<br> should observe increased power consumption and heat production.<br> So, this is another mystery as to why the perfectly normal use of hlt affec= ts<br> your system so badly.<br> <br> P.S. I hope that you noticed a list of things to look at in my previous fol= lowup<br> to this PR.<br> <span class=3D"HOEnZb"><font color=3D"#888888">--<br> Andriy Gapon<br> </font></span></blockquote></div><br></div> --047d7bb0435c686c9204e5542fed--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201309011540.r81Fe1Yc064770>