Messages in this thread | | | Subject | Re: Adaptive thread creation by the kernel | From | Andi Kleen <> | Date | 02 Feb 2000 11:58:04 +0100 |
| |
cel@monkey.org (Chuck Lever) writes: > > > It's this: when a thread blocks, you wake up another. The other thread > > was started and blocked especially for this. The other thread then > > carries on pulling things to do from your event list, until the first, > > blocked one returns from the kernel. When that happens, someone > > receives a signal or some other notification, so that one of the threads > > can stop again. > > > > Upon this simple kernel interface can be built automatic allocation > > and deallocation of threads, and on that, a simple event handling API > > that always has the appropriate number of threads to do the work. > > this is exactly what an interface like mincore() is designed for. the > application, or an underlying threads library, can use it to avoid page > faults that would block all the threads running in an address space.
But then you have to check before every access that it is most likely not swapped out. I think it would be more convenient to get some queued signal. Unfortunately that requires lots of kernel changes if you want it in the same thread (no support to handle EINTR returns from *_user and forcing SA_RESTART could cause races in the user program), but it would be possible to send it to another thread (e.g. like Single Unix sigevent SIGEV_THREAD would specify) That thread would then switch all user space threads that wait on the blocked kernel thread to another kernel thread. Doing a mincore() all the time would be too slow I think.
-Andi
-- This is like TV. I don't like TV.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |