Date: Sat, 26 Aug 2017 12:58:37 -0700 (PDT) From: Don Lewis <truckman@FreeBSD.org> To: kostikbel@gmail.com Cc: freebsd-rwg@pdx.rh.CN85.dnsmgr.net, avg@freebsd.org, freebsd-arch@freebsd.org Subject: Re: ULE steal_idle questions Message-ID: <201708261958.v7QJwbGK054320@gw.catspoiler.org> In-Reply-To: <201708261947.v7QJle5Q054291@gw.catspoiler.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 26 Aug, To: kostikbel@gmail.com wrote: > On 26 Aug, Konstantin Belousov wrote: >> On Sat, Aug 26, 2017 at 11:29:29AM -0700, Don Lewis wrote: >>> I actually haven't noticed that problem on my package build boxes. I've >>> experienced decent interactive performance even when the load average is >>> in the 60 to 80 range. I also have poudriere configured to use tmpfs >>> and the only issue I run into is when it starts getting heavily into >>> swap (like 20G) and I leave my session idle for a while, which lets my >>> shell and sshd get swapped out. Then it takes them a while to wake up >>> again. Once they are paged in, then things feel snappy again. This is >>> remote access, so I can't comment on what X11 feels like. >> >> I believe what people complain about is the following scenario: >> they have some interactive long living process, say firefox or mplayer. >> The process' threads consume CPU cycles, so the ULE interactivity >> detection logic actually classifies the threads as non-interactive. >> >> This is not much problematic until a parallel build starts where >> toolchain processes are typically short-lived. This makes them >> classified as interactive, and their dynamic priority are lower than the >> priority of long-lived threads which are interactive by user perception. >> >> I did not analyzed the KTR dumps but this explanation more or less >> coincides with the system slugginess when attempt to use mplayer while >> heavily oversubscribed build (e.g. make -j 10 on 4 cores x 2 SMT >> machine) is started. > > I can believe that. I keep an excessive number of tabs open in firefox > and it would frequenty get into a state where it would consume 100% of a > CPU core. Very recent versions of firefox are a lot better. > > Xorg is another possible victim. I've just noticed that when certain > windows have mouse focus (firefox being one, wish-based apps are > another) that the Xorg %CPU goes to 80%-90%. I think this crept in with > the lastest MATE upgrade. If Xorg is treated as non-interactive, then > the desktop experience is going to be less than optimal if there is > competing load. I've got poudriere running right now on my primary package build box. The priorties of the compiler processes are currently in the range of 74-96. On my desktop, firefox is running at priority 24. Xorg when it is not being a CPU hog gets all the way down to priority 20. When the mouse is pointing to one of the windows that makes it go nuts, then it gets all the way up to priority 98.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201708261958.v7QJwbGK054320>