Re: [9fans] system responsiveness

[forsyth@caldo.demon.co.uk]

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

>>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.

i had idly wondered about that bit: it didn't seem canonical.  serve me right for being idle.
it also explains why my own system years ago seemed more responsive
on the same hardware but i assumed that 9 was just doing much more
(which it was, of course, but that wasn't the cause).

a little off-topic but there's a similar problem in trying to
implement spin-locks in Linux and FreeBSD (using their respective
types of shared-memory processes).  the problem arises because there
seems to be no sensible locking scheme provided by the system.  (even
for implementing longer-term locks, after all these years, there seems
to be only that hopeless UNIX/TS semaphore stuff, or pipes.)

thus, we try to do spin-locks by hand using sched_yield() in the
process waiting for the lock.  there's obviously some churn as above,
but it would still be not too bad if only the processes remained at
the same priority.  if the process holding the lock happens to have earned a dynamic priority
less than the process waiting, it ends up churning away relinquishing
to every other process on its priority level (quite often only itself),
because sched_yield just puts it at the end of its current run queue.
using a fixed priority scheme would be not too bad, except
you seem to need to have a special module compiled in and
whether that's there or not, you apparently need to be super-user to use it.
having discovered this i'll probably just queue them myself but that apparently means
using the 'orrible Sys V locking crud.  better ideas on a e-postcard to me.

i mention it here rather than Linux groups because i hoped for a sensible answer,
but less unpleasantly because i have wondered whether /sys/src/libc/port/lock.c
could suffer a similar problem when the fixed priority option isn't set.

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

To: 9fans@cse.psu.edu
Subject: Re: [9fans] system responsiveness
Date: Wed, 1 May 2002 15:49:28 -0400
Message-ID: <bc9a8982e2776ece26ce90a1ea96a431@plan9.bell-labs.com>

> 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