From owner-freebsd-arch@freebsd.org Sat Aug 26 19:58:48 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 301B6DD9C8E for ; Sat, 26 Aug 2017 19:58:48 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (unknown [IPv6:2602:304:b010:ef20::f2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gw.catspoiler.org", Issuer "gw.catspoiler.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E5733776DE; Sat, 26 Aug 2017 19:58:47 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTP id v7QJwbGK054320; Sat, 26 Aug 2017 12:58:41 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201708261958.v7QJwbGK054320@gw.catspoiler.org> Date: Sat, 26 Aug 2017 12:58:37 -0700 (PDT) From: Don Lewis Subject: Re: ULE steal_idle questions To: kostikbel@gmail.com cc: freebsd-rwg@pdx.rh.CN85.dnsmgr.net, avg@freebsd.org, freebsd-arch@freebsd.org In-Reply-To: <201708261947.v7QJle5Q054291@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Aug 2017 19:58:48 -0000 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.