From owner-freebsd-current@FreeBSD.ORG Sun Jan 25 09:19:29 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 387C9106564A; Sun, 25 Jan 2009 09:19:29 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by mx1.freebsd.org (Postfix) with ESMTP id 4B4FC8FC1A; Sun, 25 Jan 2009 09:19:08 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so3806519fgb.35 for ; Sun, 25 Jan 2009 01:18:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3TZPKZmSaYW+lJfox5xMd6lbQUoVtT6Ts8WrlGAZazE=; b=OPmExmhNs1i0J0Fjam3xDjBtLf6TKYAhh869AuVQbnjIBKDUgNFKmF6NiC+JdYxRD7 2P0bmm61GFEoUpM/o0ndkXyYm7KP9ONBnTAUx4I7Wucul6AJjoraLtYBkw+txYBa0lhm YvFdafVTBfGiMmeyCtVF08tqoIEMNkNybgRfE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=aDOH+Pq3DNZcTGnjV2cx83r6/9qeCEm5GlvLhSHhDBybSBbpbP88PssdufChyctSSm hJXXduwe24YwMkRhEPiMtKavPDruvRf7LVV1m1R8VdOn1Vatm1aTFocPArvT3CYxRFkM mrKvOTGsxpsNcWXP3cLbmFiOuHYNyPz7tpErs= MIME-Version: 1.0 Received: by 10.181.28.15 with SMTP id f15mr656223bkj.75.1232875128884; Sun, 25 Jan 2009 01:18:48 -0800 (PST) In-Reply-To: <200901141804.31326.shoesoft@gmx.net> References: <7d6fde3d0901091705v6eb4c7bfxe23708f8651e2125@mail.gmail.com> <496C8A59.6090301@gmx.de> <496CA9E3.90700@mail.zedat.fu-berlin.de> <200901141804.31326.shoesoft@gmx.net> Date: Sun, 25 Jan 2009 01:18:48 -0800 Message-ID: <7d6fde3d0901250118v153b8442v97be05f4fd897928@mail.gmail.com> From: Garrett Cooper To: Stefan Ehmann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Christoph Mallon , "O. Hartmann" , freebsd-current@freebsd.org, freebsd-x11 Subject: Re: X becomes unresponsive with nvidia and hardlocks with gdb (was Re: X becomes unresponsive with nvidia / xscreensaver and desktop panics) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2009 09:19:29 -0000 On Wed, Jan 14, 2009 at 9:04 AM, Stefan Ehmann wrote: > On Tuesday 13 January 2009 15:49:07 O. Hartmann wrote: >> Christoph Mallon wrote: >> > O. Hartmann schrieb: >> >> Garrett Cooper wrote: >> >>> - I've rebuilt my xorg-server a few times and it's still claiming that >> >>> it was built with 7.1-RC2 -_-... >> >>> - I can get the Xorg server to go full tilt by just compiling >> >>> something, like buildworld, via an xterm. >> >> >> >> I also experienced this, but not only with the mentioned 'nv' driver, >> >> also with 'vesa'. Compiling a kernel or making buildworld, even with no >> >> -jX option, turns the box sometimes in a state of unresponseness. Mouse >> >> jumping, no keyboard response, sometimes for more than a minute. This >> >> happens on a FBSD 8.0-CUR/AMD64 UP box and it also happens on a FreeBSD >> >> 7.1-STABLE box (also amd64, 4 cores). But on SMP boxes I reralized that >> >> the problem does not impact that harsh as seen on UP boxes. >> >> We also had several P4 32bit machines with HTT enabled around, one of >> >> them was built with FreeBSD 7.1-STABLE AND Xorg and I never realized the >> >> bumpy X11, even when disabling HTT and running UP and Xorgs vesa driver. >> >> >> >> Well, it also seems to make no difference whether I use USB2 stack (in >> >> FreeBSD 8) or the old one. >> > >> > I regularly can observe that batch jobs like large compile jobs get a >> > lower priority number (i.e. they get preferred by the scheduler) than >> > X on my UP machine with SCHED_ULE (7.0-STABLE from early July). Just a >> > bit X activity (switching desktops, scrolling in a browser etc.) is >> > enough to make its priority number higher than that of make+gcc. >> > This also causes interesting cascades like stuttering music: >> > - gcc preferred over X >> > - X cannot redraw xterm fast enough >> > - buffer of xterm fills >> > - mplayer cannot write its status line to xterm and blocks >> > - because mplayer blocks it cannot feed more data to the sound device >> > - music stutters >> >> ... try moving/draging a xterm rapidly over your screen while playing >> music, copying a file or encoding, decoding or even compiling something. >> In my case, suddenly those activities stop running. It is sometimes only >> noticable when listening to music. >> I realised those ghost-stops also without X11 - when high disk I/O >> and/or network I/O happens. This is even harsh on a NFS-server. As I >> mentioned, this is significantly on UP boxes, but can also be watched on >> some slower/older SMP hardware (both with FreeBSD 7.1-STABLE AND FreeBSD >> 8.0-CURRENT). > > I've been observing this since 7.0 IIRC. With 6.x I never noticed this. > > When performing a portupgrade or running mencoder everything becomes very > sluggish sometimes. E.g. Redrawing windows takes several second, even > moderately sized videos can't be played back smoothly anymore. 4BSD seems to > be better than ULE but still not perfect. > > As a workaround I run load intensive tasks with idprio(1), nice(1) doesn't > really help that much. > > Unfortunately I've never been able to reduce this to a simple reproducible > test case. E.g. if Xorg has to be involved and what kind of load causes the > problems. > > But my conclusions were similar to your findings. Simply using lots of CPU > doesn't affect the responsiveness of the system. But when high disk or network > I/O is involved the problem occurs. > > Also, I figured this would not happen on every system. Otherwise there would > have been more complaints on the lists. This also seems to correlate with your > statement that the problem is significant on UP hardware, I run a 4+ years old > Athlon XP CPU. I just upgraded Xorg and manually patched the nvidia-driver Makefile to pick up the latest version from nvidia's site and I'm no longer seeing the high CPU issues with compiling like I used to, so this very problem may have gone away... The release notes for the newest driver hint at a performance regression which was caught after the fact, as well as the fact that they enabled more card features and fixed a few bugs. I submitted a ports PR for this, so hopefully it'll hit the tree in a few days. The other nvidia-driver sets should probably be updated as well. Cheers :), -Garrett