Date: Thu, 17 May 2018 08:46:27 +0100 From: Johannes Lundberg <johalun0@gmail.com> To: Andriy Gapon <avg@freebsd.org> Cc: freebsd-current <freebsd-current@freebsd.org> Subject: Re: Lag after resume culprit found Message-ID: <CAECmPwsgQhMM6zu=EfV=DQ4VHzEMuQUjD%2B45O-TP=A2U9mM8Qg@mail.gmail.com> In-Reply-To: <acaa419d-891e-96b1-7c1f-3203857c07ec@FreeBSD.org> References: <CAECmPwtULDe9GGK0PhnUa7_n=zxripJj9nh5m0RTF9XqKhXKYQ@mail.gmail.com> <acaa419d-891e-96b1-7c1f-3203857c07ec@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, May 17, 2018 at 7:43 AM, Andriy Gapon <avg@freebsd.org> wrote: > On 17/05/2018 02:07, Johannes Lundberg wrote: > > https://github.com/freebsd/freebsd/commit/66f063557f257baa9c8aeab9f93317 > 1eaa6e1cfa > > 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. > > > 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 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAECmPwsgQhMM6zu=EfV=DQ4VHzEMuQUjD%2B45O-TP=A2U9mM8Qg>