Date: Wed, 7 May 2003 13:16:08 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: David Xu <davidxu@freebsd.org> Cc: Daniel Eischen <eischen@pcnet1.pcnet.com> Subject: Re: kern_threads.c.. upcall question.. Message-ID: <Pine.BSF.4.21.0305071309120.47162-100000@InterJet.elischer.org> In-Reply-To: <003001c313a3$0de7d500$f001a8c0@davidw2k>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 6 May 2003, David Xu wrote: > > > > > > This is quantum preemptive for userland, it is used when statclock > > > interrupt hit in userland, if thread quantum is exhausted, > > > it must unbind upcall from current thread, and schedule an upcall, > > > you can think it is an implicit syscall triggered by CPU automatically > > > which just means to swap out current thread. > > > > > > ah.. > > I was thinking that we could delay most of thread_user_enter() > > until we need it.. > > i.e why read the mailbox until we need it.. > > > > I think fuword is very fast, at least in i386, there is > few instructions in fuword, please read its code in > /sys/i386/i386/support.s, optimizing it may be not worth to do. > Beside this, you can not fetch mailbox pointer on damand, > thread_schedule_upcall is protected under sched lock, it > can not handle page fault at that time, and kse_thr_interrupt > need a mailbox pointer to indentify thread in kernel, delaying > it will cause problem. Currently we cannot identify threads that are getting pagefaults or other reasons to enter the kernel except for syscall. I think there are probably ways that this can be optimised, but it is not important to do it now. > > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0305071309120.47162-100000>