kern/181632: 9.2-RC3 - on resume from suspend, disk operations are slower

Andriy Gapon avg at FreeBSD.org
Sun Sep 1 22:00:01 UTC 2013


The following reply was made to PR kern/181632; it has been noted by GNATS.

From: Andriy Gapon <avg at FreeBSD.org>
To: Mike Harding <mvharding at gmail.com>
Cc: bug-followup at FreeBSD.org
Subject: Re: kern/181632: 9.2-RC3 - on resume from suspend, disk operations
 are slower
Date: Mon, 02 Sep 2013 00:52:50 +0300

 on 01/09/2013 18:34 Mike Harding said the following:
 > 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 guess I have to trust you on this.  Isn't it simpler to just paste a few lines?
 
 > 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.
 
 I really do appreciate the investigative work that you did.
 
 > You
 > introduced it
 
 Yes, I did, without any doubt.
 
 > if it caused 'increased power consumption and heat production"
 > with the previous version, it would have been noticed by now I think.
 
 Please do not forget that 9.2-RC has other changes that no previous release of
 FreeBSD had.  Just because reverting that particular line improves things for
 you does not automatically mean that that line is to blame.  It could be that it
 just reveals a problem in an earlier commit.
 
 > As you point out, it runs rarely.
 
 My actual point was that it should not make any difference at all in a normal
 system state.  Unless the "disabled" flag got stuck somehow.
 
 > I only see this issue after a suspend/resume
 > on a desktop machine, which is not something most people do, I am sure.
 
 But some do.  Including me.
 
 > 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.
 
 I think that you misunderstood the code.  The disable calls only set flag.  hlt
 instruction is executed in acpi_cpu_idle.
 
 > 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?
 
 Yes on both accounts.
 
 > 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.
 
 Finding the root cause would be really prudent.
 
 > 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.
 
 That would be perfect.
 
 P.S.
 Thank you again for finding the commit and the line.
 I understand that you've already made conclusions based on your findings and you
 would like to see a quick action based on your findings.
 But I would like to determine a root cause and have a clear explanation of what
 exactly causes the slowdown that you see.
 So I want to ask you to try to help me as much as you can instead of trying to
 persuade me to just revert the line in question.
 
 
 
 -- 
 Andriy Gapon


More information about the freebsd-bugs mailing list