From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <1effb825dbe9487afe6eff8834c89c96@plan9.bell-labs.com>
From: presotto@plan9.bell-labs.com
To: 9fans@cse.psu.edu
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: [9fans] priority bug
Date: Thu, 28 Feb 2002 11:12:17 -0500
Topicbox-Message-UUID: 5bda9ebc-eaca-11e9-9e20-41e7f4b1d025

There are two priority classes in Plan 9, one for
kproc's and processes loaded with the kernel, and 
one for everything else.  They intersect at one
priority level, the former having the edge.  Due
to priority inheritence across fork, on the terminals
all processes fall in the first class.  If you are
getting screwed by cpu hogs, you might want to add
this to after the arg processing in init.c:

	int fd;
	char ctl[128];

	snprint(ctl, sizeof(ctl), "#p/%d/ctl", getpid());
	fd = open(ctl, OWRITE);
	if(fd < 0)
		print("init: warning: can't open %s: %r\n", ctl);
	else
		if(write(fd, "pri 10", 6) != 6)
			print("init: warning: can't set priority: %r\n");
	close(fd);

It'll drop init and everything it starts to the
lower class.

Also, you can make the kernel much more aggressive at stepping
on cpu hogs with the following change to ready() in proc.c:

change

		if(p->state == Running){
			p->rt++;
			pri = ((p->art + (p->rt<<1))>>2)/Squantum;
		} else {
			p->art = (p->art + (p->rt<<1))>>2;
			p->rt = 0;
			pri = p->art/Squantum;
		}

to

		if(p->state == Running){
			p->rt++;
			pri = (p->art + p->rt)/2;
		} else {
			p->art = (p->art + p->rt + 2)/2;
			pri = (p->art + p->rt)/2;
			p->rt = 0;
		}

It basicly gets rid of the damping so that things run up 
and down priority levels pretty quickly.  It helped rsc
when running his mp3 encoder.

Tell me of any adverse affects.  I'll stick it in the
distribution if noone is screwed by it.