9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* [9fans] priority bug
@ 2002-02-28 16:12 presotto
  2002-02-28 17:07 ` Scott Schwartz
  0 siblings, 1 reply; 3+ messages in thread
From: presotto @ 2002-02-28 16:12 UTC (permalink / raw)
  To: 9fans

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.


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [9fans] priority bug
  2002-02-28 16:12 [9fans] priority bug presotto
@ 2002-02-28 17:07 ` Scott Schwartz
  0 siblings, 0 replies; 3+ messages in thread
From: Scott Schwartz @ 2002-02-28 17:07 UTC (permalink / raw)
  To: 9fans

A while back Eran Gabber had a usenix paper on an improved scheduler.
Did that work out well enough?


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [9fans] priority bug
@ 2002-02-28 17:59 presotto
  0 siblings, 0 replies; 3+ messages in thread
From: presotto @ 2002-02-28 17:59 UTC (permalink / raw)
  To: 9fans

[-- Attachment #1: Type: text/plain, Size: 702 bytes --]

It worked but was a bit too major to stick in the normal
release.  It knew about oversubscribing and would relegate
anything that didn't have the focus to best effort.

It had the advantage of being able to have many things
going and the one you were most interested in to have
all the resource it wanted.  It scheduled not only cpu
but other resources as well.

At one point I started sticking it into the main line
but the related changes were a little too pervasive
for me so I backed out.

Now we have a real time scheduler that pb(peter bosch)
did to handle mpeg streams and other goo.  I haven't
used it but it is in our main stream so it'll at least
see the light of day someday.

[-- Attachment #2: Type: message/rfc822, Size: 1494 bytes --]

From: Scott Schwartz <schwartz@bio.cse.psu.edu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] priority bug
Date: Thu, 28 Feb 2002 12:07:57 -0500
Message-ID: <20020228170757.2886.qmail@g.bio.cse.psu.edu>

A while back Eran Gabber had a usenix paper on an improved scheduler.
Did that work out well enough?

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2002-02-28 17:59 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-02-28 16:12 [9fans] priority bug presotto
2002-02-28 17:07 ` Scott Schwartz
2002-02-28 17:59 presotto

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).