Re: [9fans] system responsiveness

Re: [9fans] system responsiveness

[Russ Cox]

> I don't recall the details, but while I was playing with
> the scheduler last fall Russ and I found that there was a
> bug with assigning priorities.  Under load the scheduler
> was a real dog; I think Russ subsequently fixed it.  Doing

Presotto put some tweaks in for me.  The processes move
around dynamically (between priority levels) a bit more now.
My particular test case was an mp3 encoder, which yielded the
processor to go to disk just often enough that it wasn't being
penalized for using so much CPU.  The scheduler is more responsive
now to long-term CPU hogs that occasionally schedule, so that
background tasks like mp3enc won't hurt your interactive
performance as much.

> so made the system noticeably snappier.  I also ran into
> some problems with what appeared to be lost clock
> interrupts, but never had the time to track things down
> completely.

This is a really cool bug.  The system would just stop
scheduling other processes, but if you moved the mouse
around that would generate enough interrupts that the
preemptive scheduler would go into effect and get you
going.  Stop the moving the mouse, stop making progress.
We never found it, and all that has been rewritten recently
so maybe it got fixed inadvertently.

Russ

Re: [9fans] system responsiveness

[forsyth]

it's nice to know i wasn't just imagining that
the system felt faster.   it's all very well
trying to measure these things, but it's
always better if the difference can be sensed.

Re: [9fans] system responsiveness

[forsyth]

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

Re: [9fans] system responsiveness

[plan9]

Exactly the same remark. FS / CPU and Term are faster on the same hardware.

The most significant demonstration is while pushing the Plan 9 replica

I had no time to stand up, not even think about the tea cup :
P3 900 MHz CPU/AUTH  <--100Mbps crossover--> P3 900 MHz File Server

I was also able to crate files directly on FS root. Hereafter is the FS configuration

1st config
  service 9fs2k
  ip 192.168.0.9
  ipgw 192.168.0.1
  ipmask 255.255.255.0
  ipauth 192.168.0.100
  config h1
  filsys main ch0fh1
  filsys dump o
  ream main
  allow
  noauth
  end

users default

Then from the CPU/AUTH machine :

9fs 192.168.0.9
mount -c /srv/192.168.0.9 /n/dist
......

Last point : I have both cached and diskless machines (getting AUTH FS from IL)

The diskless Plan 9 Terminal works fine, even for new authentication mecanisms.

<forsyth@caldo.demon.co.uk>
> i've got a full 4th edition network having upgraded
> my 3rd edition network at home.  as i use it, i keep
> thinking it feels somewhat faster than the previous
> release, on precisely the same hardware.
>

Re: [9fans] system responsiveness

[William Josephson]

On Wed, May 01, 2002 at 08:13:03PM +0100, forsyth@caldo.demon.co.uk wrote:
> i've got a full 4th edition network having upgraded
> my 3rd edition network at home.  as i use it, i keep
> thinking it feels somewhat faster than the previous
> release, on precisely the same hardware.

I don't recall the details, but while I was playing with
the scheduler last fall Russ and I found that there was a
bug with assigning priorities.  Under load the scheduler
was a real dog; I think Russ subsequently fixed it.  Doing
so made the system noticeably snappier.  I also ran into
some problems with what appeared to be lost clock
interrupts, but never had the time to track things down
completely.  As rob pointed out, the new 9p makes a
difference, too.

Re: [9fans] system responsiveness

[rob pike, esq.]

The new all-singing all-dancing 9P helps too, by reducing the number
of messages to evaluate a file name and a number of other lesser
improvements.

-rob

Re: [9fans] system responsiveness

[Sape Mullender]

> 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

Re: [9fans] system responsiveness

[Scott Schwartz]

| i've got a full 4th edition network having upgraded
| my 3rd edition network at home.  as i use it, i keep
| thinking it feels somewhat faster than the previous
| release, on precisely the same hardware.

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

[9fans] system responsiveness

[forsyth]

i've got a full 4th edition network having upgraded
my 3rd edition network at home.  as i use it, i keep
thinking it feels somewhat faster than the previous
release, on precisely the same hardware.