From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@cse.psu.edu Subject: Re: [9fans] system responsiveness From: forsyth@caldo.demon.co.uk MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-epqbfcuhhcqkdvrmeqtowbejwy" Date: Thu, 2 May 2002 06:18:18 +0100 Topicbox-Message-UUID: 83eb3c2c-eaca-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-epqbfcuhhcqkdvrmeqtowbejwy Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit >>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. --upas-epqbfcuhhcqkdvrmeqtowbejwy Content-Type: message/rfc822 Content-Disposition: inline Return-Path: <9fans-admin@cse.psu.edu> Received: from punt-2.mail.demon.net by mailstore for forsyth@caldo.demon.co.uk id 1020282630:20:29541:147; Wed, 01 May 2002 19:50:30 GMT Received: from psuvax1.cse.psu.edu ([130.203.4.6]) by punt-2.mail.demon.net id aa2102303; 1 May 2002 19:50 GMT Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.8.6]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 55175199E3; Wed, 1 May 2002 15:50:06 -0400 (EDT) Delivered-To: 9fans@cse.psu.edu Received: from plan9.cs.bell-labs.com (plan9.bell-labs.com [204.178.31.2]) by mail.cse.psu.edu (CSE Mail Server) with SMTP id 20CF219980 for <9fans@cse.psu.edu>; Wed, 1 May 2002 15:49:32 -0400 (EDT) Message-ID: To: 9fans@cse.psu.edu Subject: Re: [9fans] system responsiveness MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: 9fans-admin@cse.psu.edu Errors-To: 9fans-admin@cse.psu.edu X-BeenThere: 9fans@cse.psu.edu X-Mailman-Version: 2.0.9 Precedence: bulk Reply-To: 9fans@cse.psu.edu List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu> List-Archive: Date: Wed, 1 May 2002 15:49:28 -0400 > 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 --upas-epqbfcuhhcqkdvrmeqtowbejwy--