On Wednesday 28 June 2006 20:04, Helge Bahmann wrote: > > No, It's a latency thing in a distributed system. Basically thread B can both > > be I/O-bound and CPU-bound. In the first case I want to avoid context > > switching in order to minimize latency. In the later communication should > > continue (servicing/forwarding requests), while thread B is doing > > computation. > > what about simply letting thread A/thread B race for event notification? > with epoll you can do that (with plain poll obviously you cannot...), and > you always get perfect latency (but you don't know which thread will > eventually handle the event) That will not work, because it's thread B that needs the data fetched by event handling. Perhaps I should be more precise: The events are input events from a set of TCP socket. Thread A handles input from these sockets and updates state in a subsystem. Thread B calls into the subsystem to ask for input. If the required input is not available it has to request it from other nodes in the distributed system and wait for a reply. In order to minimize the input path for thread B, it should do the input handling until the request are replied. > > > however all that still begs the question why you don't just let the > > > threads swap roles > > > > The threads have very different call stacks. Also, this would not solve the > > context switching issues. > > this is really whacky, but... you *could* use setcontext and friends to > switch to the other thread's call stack after returning from poll/epoll > (instead of taking over event waiting in the other thread) -- basically > you replace a kernel context switch with a user-space context switch I'm seeing how this would work. Both threads would have to wait in a similar poll and wakeup behavior is undefined in this case. > are you sure this kind of micro-optimization is really required in your > case? If one thread is compute-bound, the scheduler will usually do the > right thing Well this is research and I'm trying to push TCP communication as far as possible in user-space without modifying the kernel. Thanks for all your input. Hans - : send the line "unsubscribe linux-net" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
