Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 27 Nov 1999 04:04:03 -0800 (PST)
From:      Julian Elischer <julian@whistle.com>
To:        "Daniel M. Eischen" <eischen@vigrid.com>
Cc:        arch@freebsd.org
Subject:   Re: Threads stuff
Message-ID:  <Pine.BSF.4.10.9911270403410.544-100000@current1.whistle.com>
In-Reply-To: <383FC334.F96FDAB1@vigrid.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Now that is a good idea.. :-)


On Sat, 27 Nov 1999, Daniel M. Eischen wrote:

> 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?Pine.BSF.4.10.9911270403410.544-100000>