From owner-freebsd-current@FreeBSD.ORG Tue Jan 13 13:50:16 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 9672B1065670 for ; Tue, 13 Jan 2009 13:50:16 +0000 (UTC) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from mail-gw2.york.ac.uk (mail-gw2.york.ac.uk [144.32.128.247]) by mx1.freebsd.org (Postfix) with ESMTP id 429908FC08 for ; Tue, 13 Jan 2009 13:50:16 +0000 (UTC) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from mail-gw6.york.ac.uk (mail-gw6.york.ac.uk [144.32.129.26]) by mail-gw2.york.ac.uk (8.13.6/8.13.6) with ESMTP id n0DDoDNq025359; Tue, 13 Jan 2009 13:50:13 GMT Received: from buffy-128.york.ac.uk ([144.32.128.160] helo=buffy.york.ac.uk) by mail-gw6.york.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1LMjen-0003oF-Du; Tue, 13 Jan 2009 13:50:13 +0000 Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.14.2/8.14.2) with ESMTP id n0DDoDQd071688; Tue, 13 Jan 2009 13:50:13 GMT (envelope-from gavin.atkinson@ury.york.ac.uk) Received: (from ga9@localhost) by buffy.york.ac.uk (8.14.2/8.14.2/Submit) id n0DDoCY1071687; Tue, 13 Jan 2009 13:50:12 GMT (envelope-from gavin.atkinson@ury.york.ac.uk) X-Authentication-Warning: buffy.york.ac.uk: ga9 set sender to gavin.atkinson@ury.york.ac.uk using -f From: Gavin Atkinson To: Christoph Mallon In-Reply-To: <496C8A59.6090301@gmx.de> References: <7d6fde3d0901091705v6eb4c7bfxe23708f8651e2125@mail.gmail.com> <7d6fde3d0901111853k40f26893j722d95d3556c820@mail.gmail.com> <496C5F37.4070006@mail.zedat.fu-berlin.de> <496C8A59.6090301@gmx.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 13 Jan 2009 13:50:12 +0000 Message-Id: <1231854612.70382.15.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 FreeBSD GNOME Team Port X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin.atkinson@ury.york.ac.uk Cc: Garrett Cooper , "O. Hartmann" , Doug Barton , freebsd-x11 , FreeBSD Current Subject: X unresponsive with SCHED_ULE (was: Re: X becomes unresponsive with nvidia and hardlocks with gdb) 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: Tue, 13 Jan 2009 13:50:16 -0000 On Tue, 2009-01-13 at 13:34 +0100, 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. Yes, ULE does still have a few issues, especially with jobs that should have a low priority getting the CPU when higher priority jobs should have it. This is especially noticeable with processes that want to use 100% cpu but are supposed to run at idprio (a good example is ports/misc/dnetc) - and is why my desktops are still using 4BSD. If you can retest with SCHED_4BSD, it would be worth doing so. Gavin