From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <bc9a8982e2776ece26ce90a1ea96a431@plan9.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] system responsiveness
From: Sape Mullender <sape@plan9.bell-labs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Date: Wed,  1 May 2002 15:49:28 -0400
Topicbox-Message-UUID: 834c59ae-eaca-11e9-9e20-41e7f4b1d025

> On a similar topic, how is the realtime scheduler working out?

It only works out when you let it.

Basically, a process can do
	fd = open("/dev/realtime/task/clone", ORDWR);
	if (fprint(fd, "T=30ms D=10ms C=2ms procs=self admit") < 0)
		sysfatal("Can't run real time");
	for(;;){

		/* do real time stuff */

		fprint(fd, "yield');
	}

T is the period, D the deadline, C the cost (i.e., the process gets at most C ms worth of cpu
cycles in the first D ms of each period of T ms).

Currently, the system guarantees that a process can get C per period, but it also
guarantees it cannot get more.  Maybe we'll add extra time under best-effort scheduling.

It used to be the case that, when a process tries to get a kernel lock and the lock is
not available, the process would lower its priority and wait.  There was no mechanism
to hurry the process holding the lock along while (for example) a real-time process was
waiting.  We changed the scheduler:  Now, a process holding a lock (NOT a qlock) is
not scheduled until it gives up the lock.  We think this is one of the causes for the
faster feel of the system -> less thrashing.

	Sape