Date: Sat, 27 Nov 1999 06:40:36 -0500 From: "Daniel M. Eischen" <eischen@vigrid.com> To: Julian Elischer <julian@whistle.com> Cc: arch@freebsd.org Subject: Re: Threads stuff Message-ID: <383FC334.F96FDAB1@vigrid.com> References: <Pine.BSF.4.10.9911270218430.544-100000@current1.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Julian Elischer wrote: > > ok well I'm only sketching out one solutionso don't feel that ai'm > bullying you into anything.. > > in this scheme however there is nothing to say that we can't keep track of > time spent in IO. As long as the UTS was informed of the time spent in the kernel (I suppose via the IO control block?) for each KSE, then that would probably be good enough. Currently under libc_r, it is almost inevitable that every thread switch needs to make a system call or two, even if you ignore setting the signal masks and use _setjmp/_longjmp. We have to call gettimeofday() to get the time, calculate the time that the current thread should be switched out (assuming it doesn't block before then), and make a call to setitimer(). If we are going to try and optimize away the system call needed to resume a thread after its work in the kernel is completed, then let us also look at other ways to eliminate system calls :-) If the upcall that notifies the UTS of unblocked threads also supplies the current time, as well as time spent in the kernel for each completed KSE, then that would eliminate the need to perform gettimeofday(). We still need to schedule some sort of signal (or upcall) to tell us when the current threads quantum has been reached. If we supply a thread_resume_with_quantum(), then we can resume the thread and schedule the signal (or whatever) all in one system call. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?383FC334.F96FDAB1>