From owner-freebsd-hackers Tue Sep 10 20:15:23 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA04091 for hackers-outgoing; Tue, 10 Sep 1996 20:15:23 -0700 (PDT) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA04086 for ; Tue, 10 Sep 1996 20:15:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.5/8.6.5) with SMTP id UAA20331; Tue, 10 Sep 1996 20:15:35 -0700 (PDT) Message-Id: <199609110315.UAA20331@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: "Daniel O'Callaghan" cc: hackers@freebsd.org Subject: Re: undocumented kernel priority changing In-reply-to: Your message of "Wed, 11 Sep 1996 08:15:05 +1000." From: David Greenman Reply-To: dg@root.com Date: Tue, 10 Sep 1996 20:15:35 -0700 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> >Michael Smith: >> >>> (10 minutes cpu time even on a 100 MHz 586 is pretty a lot ;) >> > >> >DG: >> >} FreeBSD already has a sophisticated mechanism for controlling process >> > >> >> Actually, it has a great effect on interactive performance. The algorithm >> for priority calculation in FreeBSD is significantly different from the one in >> 4.4BSD. For one thing, we take into account the CPU consumption of all of the >> processes in the job. >[snipped] >> ratio of CPU given to 'background' processes - and there is no way that the >> kernel can make any good arbitrary decision about this. > >Hmm, I actually like the automatic renicing when programs such as vi and >pine run away with the CPU when their tty disappears. The machine is >still usable interactively. As I've already said, it's not the 'renicing' that makes the machine continue to be usable interactively, but rather the other parts of the dynamic scheduling algorithm. Removing the 'renicing' should have little or no affect on the problems you've mentioned. I should also point out that run-away pine processes are caused by bugs in pine and should be fixed, not smoothed over with some kernel hacks. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project