From owner-cvs-src@FreeBSD.ORG Wed Sep 8 07:22:05 2004 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9547816A513; Wed, 8 Sep 2004 07:22:05 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E2D143D41; Wed, 8 Sep 2004 07:22:05 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.11/8.12.11) with ESMTP id i887LqGW040507; Wed, 8 Sep 2004 00:21:56 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200409080721.i887LqGW040507@gw.catspoiler.org> Date: Wed, 8 Sep 2004 00:21:52 -0700 (PDT) From: Don Lewis To: phk@phk.freebsd.dk In-Reply-To: <34626.1094625991@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: jroberson@chesapeake.net cc: src-committers@FreeBSD.org cc: scottl@FreeBSD.org cc: cvs-all@FreeBSD.org cc: cvs-src@FreeBSD.org Subject: Re: cvs commit: src/sys/alpha/conf GENERIC src/sys/amd64/conf GENERIC src/sys/i386/conf GENERIC src/sys/pc98/conf GENERIC src/sys/sparc64/conf GENERIC X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2004 07:22:06 -0000 On 8 Sep, Poul-Henning Kamp wrote: > In message <20040908024335.T26496@mail.chesapeake.net>, Jeff Roberson writes: > >>What's not working well enough with ULE to run with it? > > On thing I have observed on my laptop is that it can take up to 30 seconds > for a process to get a signal counting from when I type CTRL-C. There is also the problem that CPU bound processes that are "nice" get the same or slightly more CPU time than CPU bound processes that are not "nice" when they are both in competition for CPU cycles. The problem is that both converge on the same priority, and even though the less nice processes are assigned a longer time slice, they keep getting put at the end of the run queue before they have used up their slice.