Lag after resume culprit found
Andriy Gapon
avg at FreeBSD.org
Thu May 17 08:06:53 UTC 2018
On 17/05/2018 10:56, Johannes Lundberg wrote:
>
>
> On Thu, May 17, 2018 at 8:46 AM, Johannes Lundberg <johalun0 at gmail.com
> <mailto:johalun0 at gmail.com>> wrote:
>
>
>
> On Thu, May 17, 2018 at 7:43 AM, Andriy Gapon <avg at freebsd.org
> <mailto:avg at freebsd.org>> wrote:
>
> On 17/05/2018 02:07, Johannes Lundberg wrote:
> > https://github.com/freebsd/freebsd/commit/66f063557f257baa9c8aeab9f933171eaa6e1cfa
> <https://github.com/freebsd/freebsd/commit/66f063557f257baa9c8aeab9f933171eaa6e1cfa>
> > x86 cpususpend_handler: call wbinvd after setting suspend state bits
>
> That's very interesting and surprising.
> That commit changes something that happens before suspend, it should not
> have
> any effect on the system state after resume.
>
> Does anyone have a theory of what could be wrong?
>
>
> Nope but moving
> CPU_CLR_ATOMIC(cpu, &suspended_cpus);
> back to the end of that scope fixes it.
>
>
>
> I did some further testing.
> Calling
> CPU_CLR_ATOMIC(cpu, &suspended_cpus);
> before
> pmap_init_pat();
> is what "breaks" resume.
>
> Is this Intel only or this it happen on AMD as well (which this patch was
> intended for)?
Not sure about the PAT part, but fpuresume/npxresume would affect all platforms.
It's a bit puzzling that doing PAT manipulations on one AP while another AP is
being brought up is problematic. Probably there is something that I am missing.
Thank you very much again for zeroing in on it.
> > How to test (i915kms)
> >
> > Start X with glxgears
> > Confirm running stable at 60 fps
> > suspend/resume (S3)
> > glxgears is now fluctuating between 10-40 fps.
--
Andriy Gapon
More information about the freebsd-current
mailing list